Skip to Content

RE: Objects in SU24

Hi all,

I went through lot of SU24 threads in SDN and also wikipedia but everytime when i think about SU24 i still get some questions in my mind.

For EX: i had a look at SU01 program code and searched the code with 'AUTHORITY-CHECK' and it contains the following 5 objects.

S_DEVELOP

S_USER_AUT

S_USER_PRO

S_USER_GRP

S_USER_SYS

but in SU24 it is showing the below 53 objects. where do these objects come from and why they are in there

if they are not even hard coded or needed in the prorgam.

i thought all the Objects that are in the program will be in SU24 and based on the navigation/flow or requirement we activate and deactivate them.just confused whats the wrong here with me in understading this?

B_ALE_MODL

B_ALE_RECV

P_ABAP

P_ORGIN

P_ORGXX

P_PCLX

P_PERNR

P_TCODE

PLOG

S_ADDRESS1

S_ADMI_FCD

S_ALV_LAYO

S_APPL_LOG

S_ARCHIVE

S_BCSETS

S_BDS_DS

S_BTCH_ADM

S_BTCH_JOB

S_BTCH_NAM

S_C_FUNCT

S_CTS_ADMI

S_DATASET

S_DEVELOP

S_DOKU_AUT

S_GUI

S_IDOCCTRL

S_IDOCDEFT

S_IMG_GENE

S_LDAP

S_OC_DOC

S_OC_ROLE

S_OC_SEND

S_OLE_CALL

S_PACKSTRU

S_PRO_AUTH

S_PROGRAM

S_PROJECT

S_RFC

S_SPO_DEV

S_TABU_CLI

S_TABU_DIS

S_TCODE

S_TRANSLAT

S_TRANSPRT

S_USER_AGR

S_USER_AUT

S_USER_GRP

S_USER_PRO

S_USER_SAS

S_USER_SYS

S_USER_TCD

S_USER_VAL

S_WFAR_OBJ

Thanks in Advance,

SS

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Best Answer
    avatar image
    Former Member
    Aug 05, 2010 at 08:52 PM

    The reason for it is not easy to spot at first... but is logical:

    In SAP's own development systems the RZ11 parameter transport/systemtype is set to "SAP". In customer systems it is set to 'CUSTOMER'.

    When the system type is SAP, the system ignores all authority-check statements until there is a check indicator set in SU22. This "forces" the developers to maintain the objects - indicating that a user in the transaction context could have the capability of navigating into the workbench or jobs or file system etc. Therefore these objects all appear in virtually all transactions. It is only those objects for which there is a consistent intended use of the transaction that SAP activates the "Proposal" flag (previously "Check/Maintain") and add as many usefull values to the fields so that customers do not need to re-trace everything. This process is also automated to a large extent in these systems.

    In CUSTOMER type systems, it is different. AUTHORITY-CHECK statements are independent of the "check" flag in SU24, but the values are still there to indicate the transaction's capabilities and those of the ABAP development workbench in particular. This arises to the urban legend that if the object does not have a "check" indicator, then it is not checked. This is only the case in SAP type systems.

    In customer systems you can globally deactivate some of the objects for all transactions in AUTH_SWITCH_OBJECTS or override the return-code (sy-subrc = 0) in SU24 for specific transaction contexts only using the "no check" indicator.

    Hope this helps you understand the origin of the 53 objects. For day-to-day purposes in customer systems you can just think of them as documentation which you will very seldom need.

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Julius,

      Thanks a million for your good explanation.

      Thanks,

      SS

      Edited by: sun on Aug 6, 2010 4:35 PM

      Edited by: sun on Aug 6, 2010 4:36 PM

  • avatar image
    Former Member
    Aug 05, 2010 at 06:37 PM

    Sun,

    Only check maintain objects will be present in the program.

    Thanks,

    Sri

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Aug 05, 2010 at 06:57 PM

    Hi Sun,

    Just to make it clear why dont you enable one object from your list in DEV environment, go back to the program and check it if the object enabled shows up.

    I always think all transactions reside in a repository , all the activated and underlying objects are called by the programs based on the transaction we call.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Aug 08, 2010 at 08:59 AM

    Hi Sun,

    The reason why they differ is that SU24 is utilised for the role administration process and has no bearing on the actual authority checks.

    SU24 is utilised by the profile generator (PFCG). It enables you to add or remove objects to the USOBT_C and USOBX_C tables. When utilising PFGC, you choose TCodes to create roles. When you select TCodes in the u2018Menuu2019 tab in PFCG, SAP refers to these two tables to propose the objects in the u2018Change Role: Authorizationsu2019 screen (visible via the u2018Authorizationsu2019 tab). As such, you can use SU24 to alter the objects proposed by the profile generator to make the role administratoru2019s jobs easier.

    The authorisations checked by the actual TCode are embedded in the program as the authority-check statements which you have mentioned.

    An example would be if you create a custom TCode called ZPOST with underlying program ZPOSTPROGRAM. The ZPOSTPROGRAM has three authority checks in it for objects Z_OBJ_CUST1, Z_OBJ_CUST2, and Z_OBJ_CUST3. However, SU24 was used to update the USOBT_C and USOBX_C tables so that ZPOST is linked to Z_OBJ_CUST1 and Z_OBJ_CUST2 only. This means that when PFCG is used for role maintenance only Z_OBJ_CUST1 and Z_OBJ_CUST2 will be proposed as objects to maintain for the role. However, you would still need all three objects to be able to utilise ZPOST transaction as this is dictated by the ZPOSTPROGRAM. Without all three you cannot carryout the ZPOST transaction as you will fail the authority checks.

    This is why there is always a potential for the SU24 objects to not match the objects actually required by the TCode or program. I normally use SU03 when trying to identify the objects required for a TCode or program by building bare roles and adding one object and value per authority check failing. Though this is more time consuming, it is the most accurate way to identify the correct auth checks (short of reading through all the ABAP code). 😉

    SU24 is normally a good place to start to identify the correct objects but as you can see, it may not be accurate.

    Hope this helps,

    Jamie

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Your partially correct answer is only partially complete --> you also cannot deactivate checks on objects in the HR object class 😊

      Regarding your test with editing the DB table, this feature has been disabled in the standard system now. It had something to do with foreign keys and application buffers - but I'll save that story for a rainy day.

      Cheers and also welcome to SDN,

      Julius

  • avatar image
    Former Member
    Aug 09, 2010 at 08:14 AM

    Hi

    In SU24 you got whole objects related to TCode SU01 but in authorization check only Yes mention object is included only by default which satisfy minimum requirment, Rest displayed Authorization object may be included by pfcg >Authorization > add manually if any specific requirment is there.

    Thanks

    Manish Gupta

    Add comment
    10|10000 characters needed characters exceeded

    • >

      > Hi

      >

      > In SU24 you got whole objects related to TCode SU01 but in authorization check only Yes mention object is included only by default which satisfy minimum requirment, Rest displayed Authorization object may be included by pfcg >Authorization > add manually if any specific requirment is there.

      >

      >

      > Thanks

      > Manish Gupta

      Hi Manish,

      If the auth object is required then updating SU24 is usually the best approach, not entering auths manually in the role.