Skip to Content

Have you ever wondered because of a new instance of an auth object being pulled in when you just deleted a transaction code from a role?

New auth object pulled in role is expected and is also obvious when a transaction code is added to a role, but at first thought it looks weird when you see a new auth object instance pulled in due to removal of a t-code.

When you dig it up you realize that this is not because of the t-code you removed but some other one already available in the role which just pulled in because some action of yours on the role. Change document will have your user id as “added by”. Let`s understand the behavior of profile generator to get the clear picture.

Whenever you touch menu items of a role (add/remove t-code) and then switch to adjust authorizations (auth tab) the profile generator refers to SU24 data of all the t-codes available in the menu (not only for the one you added/deleted) and searches the exact match of field values in standard or maintained auth objects within role (whether active or inactive) and if found missing then it pulls in a new instance of such auth objects as maintained in profile generator table USOBT_C.

Scenarios when a new auth instance will be pulled for a t-code (already available in role) whenever role menu is adjusted (another t-code is added to or deleted from the role)

  • In past while adjusting authorizations if you have changed the status of an object from “standard” to  “changed”  i.e. from standard.JPG tochanged.JPGby altering the default values
  • In past while adjusting authorizations if you have deleted a standard authorization object

Reason why it`s always advisable not to delete or change standard authorizations rather make a copy of standard authorization adjust it as per need and deactivate the original standard authorization. 

So, coming back to our initial point the auth instance of an object pulled in when you deleted a t-code in role is not because the t-code which was deleted but it`s because of a t-code already available in role for which standard object was tampered. The best practice is to deactivate any new authorizations pulled in if it is not because of the t-code added (or deleted as in this case) by you. This will avoid such occurrence in future.

So by default whenever menu items of a role got changed profile generator refers to SU24 data and brings in new authorizations in role if required. If you want to control the default behavior of profile generator you can do it by entering in Expert mode of profile generator

e mode.jpg

This will give you three different ways (maintenance types) to adjust profile

/wp-content/uploads/2012/10/expert_mode_145439.jpg

Option 1: Delete and recreated profile and authorizations

            With this option all the previously maintained authorizations within profile will be deleted and profile generator will fetch fresh SU24 data for all the t-codes available in role menu. This would be a complete profile recreation and all values maintained, changed and authorization objects added manually will be lost and need to be redone if they are needed back.

Option 2: Edit old status

            Whenever role menu is adjusted profile generator will refer SU24 data, for some reason if you want profile generator not to refer SU24 data (eventually no adjustment in authorizations automatically) then you need to select this option. Irrespective of the tcode added/deleted in menu this option will keep the same authorizations as available in role the last time it was saved. Last saved (not generated) authorizations can be seen, adjusted for regeneration of profile. No authorization will be pulled in nor deleted from the role.

Option 3: Read old status and merge with new data

            Most commonly used and is same as normal change mode (if menu is adjusted) i.e. profile generator will refer to SU24 data and bring in new authorizations in role if needed with no loss of previously maintained authorization. In other words new authorizations will be added on top of old authorizations which can be then adjusted for regeneration of profile. It becomes necessary to opt for this option when you adjust SU24 data for a t-code and want the adjusted values to be pushed in the roles containing this t-code without touching the menu items.

Hope this gives a clear understanding of Profile Generator`s behavior and helps you to deal with unusual situations during profile generation.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Julius von dem Bussche

    Yes, you can dig a very deep hole for admins who have to maintain your roles in future by using the “edit old status” radio button. Happens often.

    If would be nice to have a PRGN_CUST setting to deactivate that feature…! 

    Then such folks MUST reads the docs and not get proper training – before the train leaves the station at “go-live”.

    Most roles get screwed up shortly after “go-live”…  🙁

    Cheers,

    Julius

    (0) 
  2. Julius von dem Bussche

    BTW: There is a very special case, when even for a “fully merged” role it can happen that only removing a tcode from the menu will add a new authorization instance.

    10 beers for anyone who can explain how that can happen…  🙂

    Little tip: there is no “unmerge” option in expert mode…

    Cheers,

    Julius

    (0) 

Leave a Reply