Skip to Content
avatar image
Former Member

Authorization objects - USOBT_C and USOBX_C

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,

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    avatar image
    Former Member
    Oct 24, 2010 at 02:58 PM

    From the coding!

    What else were you expecting?

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member 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