Authorization objects - USOBT_C and USOBX_C

[Former Member]

I'll be glad if somebody could help me with the following question:

We are trying to find the authorization objects and proposed values associated to some transaction codes. We have taken transaction code V-50 and checked it in tables USOBT_C, USOBX_C, USOBT and also USOBX. The tcode doesn't have any authorization objects or proposed values in those tables. However, when we create a role (PFCG) with V-50 (only) in it, authorization objects V_KONH_VKO and V_KONH_VKS show up with proposed values. Where is this information coming from?

Thanks in advance,

[Former Member]

From the coding!

What else were you expecting?

Cheers,

Julius

[Former Member]

Thanks for your response. I was expecting to find the proposed authorization objects and values in these tables. That's what I find in the SAP documentation and how I thought it works. Don't the proposed values in PFCG come from tables and it is actually something that can be customized? If it is code then how can it be customized without changing the programs? Additionally, that's how it works for other tcodes.

I am thinking this most be stored in tables.

Thanks in advance,

[Former Member]

Ahh, that's different.

Proposals are also pulled from the "core" transactions for parameter type tcodes when the param is not maintained.

Check in SE93 for the core tcode, and look in SU24 for that one (which is what PFCG does as well)

Cheers,

Julius

[Former Member]

Thanks, that was the answer

[Former Member]

Note that the proposals are pulled for each object from the core transaction (defined as a parameter in table TSTCP) and only "overwritten" by PFCG if the parameter tcode itself has that object maintained in any way in Su24.

You can also see this "origin" in PFCG itself by clicking on the where-used "icon" (looks like a sunrise over the Alps). It will show the core transaction for you, even although it is not in the role menu.

Depending on the core transaction used and how it is called and how it is constructed, you can (generally) assume that the user will also have access to this "core" transaction.

For SPRO parameter tcodes, as an example, it makes sense to always maintain S_TABU_DIS - because otherwise you will be proposed strange activities which do not exist or force you to use "changed" auths and blank "auth group" fields for SM30, SE16, SM31, etc...).

My first response was based on an irritation that many folks believe SU24 can add checks to code, or no Su24 data means no checks are performed (I initially misunderstood your question).

Even worse is using USOB* tables to make conclusions about transactions for reporting purposes.

Worst of all is mindless maintenance of SU24 so that the reporting works, but causes no end of havoc in the real roles which real users have access to in real code at runtime.

Thanks for clarifying (and giving me the opportunity to rant a bit...

Has anyone else noticed this nasty "side effect" in release upgrades?

Cheers,

Julius