Authorization object B_BUPA_FDG

[wjvanveen]

Hi,

We are working on tightening our authorizations on business partners.

We have introduced the B_BUPA_FDG, so on field group.

Also field groups have been added to customizing (define field group for authorizations).

In authorization trace we see that user is NOT authorized for field group, but still in this case the address can be changed.
User has display authorization for field group, but not change authorization.

Are we overlooking something?

Regards,

Walter van Veen

[kchillagundla]

This message was moderated.

[michael_kozlowski]

Hi,

did you working in CRM? Which system version? GUI or Web UI?

I remember that there was some issue with Web UI.

[wjvanveen]

This is an ECC 617 system, so no CRM and no special WEB UI.

[michael_kozlowski]

Hi,

please set a BREAK-POINT in FM shown below to find out what's going wrong.

[wjvanveen]

Hello Michael,

This FM is not touched.

The stack shows that: SCREEN_TEST_VISIBILITY and BUS_FMOD_FIELDS_DISP is touched.

With the last module the check on fieldgroup is executed.

Regards,

Walter

[michael_kozlowski]

Hi,

please check OSS-Note http://service.sap.com/sap/support/notes/2106594

[wjvanveen]

Hi,

The SAP note does not work, I am in change mode, not create mode.

Maybe I am overlooking something.

[michael_kozlowski]

Hi, verify table TBZ3W columns OBLIND and X_CUSTAUS. Maybe this will be helpful.

[wjvanveen]

Hi, with lot's of debugging I found out that it has to do with the EEW (Easy Enhancement Workbench). The generated code by EEW, does not set fields etc. to display.

Does the generated code from EEW also looks into the TBZ3W settings?

[michael_kozlowski]

Hi, I didn't use EEW. Unfortunately I can not assists you in this case.

[former_member326788]

Walter,

In adding to Michael's comments, please let us know which tcode(s) you're utilizing this auth object with. Our company uses ICWeb which can be a bear to troubleshoot ICWeb auth failures. If you're also using ICWeb, creating a trace (ST01) for all auth object checks, RFC calls, and HTTP calls will help (i.e. log one user from time of login to auth failure). If there's no auth failure when the user attempts the task, look at the trace data at the time of login (when their user master buffer is loaded).

To help dissect trace data in CRM, I've found reviewing the UI_COMP components in table CRMC_UI_COMP_IP (Inbound Plug Definition), to be invaluable to understanding trace failures and components within a security role that allows this access. I've also found that by adding a menu button (for example Contract Management), allows change access even though all security auth objects are set to display only (i.e. there might be a RFC or program being called, or configuration that's allowing change access).

Any who, hopefully this info helps.

Cheers,

Greg

[wjvanveen]

This is an ECC 617 system, so no CRM and no special WEB UI.

[wjvanveen]

This is an ECC 617 system, so no CRM and no special WEB UI.