Disable Merging of Authorizations During Menu Maintenance in PFCG

[Former Member]

Hi Experts,

Wanna ask if it is possible to stop SAP from automatically merging the authorizations (i.e. removing repetitive authorization objects, combining authorization objects to logical groupings) everytime I edit the transaction code assignment at the "Menu" tab in PFCG? I observe that SAP automatically updates the authorization objects everything I add/remove transaction codes in the authorization menu.

The reason that the automatic merging of authorization is not desirable for our case is that we want to maintain certain format of our authorization objects. E.g. if there is a tcode XXX that requires read acess to 3 infotype 0000, 0001, 0002 and another tcode YYY that requires read access to 2 infotypes 0003, 0004. In this case, we would configure 2 rows for P_ORGIN object (1 for read access to 3 infotypes, another for read access to 2 infotypes). By default when updates are done in the menu, SAP merges all the 5 infotypes into 1 entry for read access. Our desired behavior is that the merging can be disabled so that the we can easily remove the corresponding infotype access when the a tcode is removed.

Experts, please advice whether the above is possible and any best practices for my above sceanrio?

Thanks and Regards.

[Former Member]

Donu2019t user export mode with merge with new value

Instead of this user normal change mode it will not merge with old value same disable from menu

[Former Member]

Hi Ravi,

Thanks for the quick reply.

It would be helpful if you can provide a more details on the steps to disable the automatic merge.

Thanks again.

[arpan_paik]

Donu2019t user export mode with merge with new value
Instead of this user normal change mode it will not merge with old value same disable from menu

Hi Ravi,

When you'll edit the role menu this will NOT work.

Hi Khai,

When you edit the role menu then generate the role profile in expert mode>>edit old status. Then note all the object manually that need to be maintain as per your requirement (this will be hectic).

Now come out with out generating profile. Now go for either normal change mode or expert mode>>read old status merge with new data. Now maintain all those manually noted object as per your need.

There is no other short cut to this particular requirement I'm afraid.

Arpan

Edited by: Julius Bussche on May 26, 2009 8:08 PM

Code tags replaced by Quote tags, to fix the formatting...

[Frank_Buchholz]

When you edit the role menu then generate the role profile in expert mode>>edit old status. Then note all the object manually that need to be maintain as per your requirement (this will be hectic).
Now come out with out generating profile. Now go for either normal change mode or expert mode>>read old status merge with new data. Now maintain all those manually noted object as per your need.

Following this way works fine, however, you have to ensure that you never choose the button Change Authorization Data instead of Expert Mode for Profile Generation again. To reduce this risk I suggest that you deactivate but not delete all unwanted Standard authorization proposals in the role after you have initially got authorization proposals. This prevents the PFCG to add these proposals again. (Another rule is, that you only fill empty fields of authorization proposals in a role, but you should never modify existing values. If the values do not match your requirements, you can deactivate the proposal and add the required data manually.)

Kind regards

Frank Buchholz

[Former Member]

> ... we want to maintain certain format of our authorization objects. E.g. if there is a tcode XXX that requires read acess to 3 infotype 0000, 0001, 0002 and another tcode YYY that requires read access to 2 infotypes 0003, 0004. In this case, we would configure 2 rows for P_ORGIN object (1 for read access to 3 infotypes, another for read access to 2 infotypes).

That is what SU24 is designed to do. Why not maintain two neat "rows" - one for each transaction.

> By default when updates are done in the menu, SAP merges all the 5 infotypes into 1 entry for read access.

What is your problem with this. It is the access which counts, and not the number of "rows".

> Our desired behavior is that the merging can be disabled so that the we can easily remove the corresponding infotype access when the a tcode is removed.

If you really want this, then either disable all authorization proposals in SU24 to "check" only, or, use SU02 and SU03 like in the olden days.

In both cases you will need to re-invent the wheel each time and work in an environment which is very error prone.

That is exactly what the development work in SU24 and the role administration via the menu objects (S_USER_TCD and S_USER_VAL) set out to avoid - namely a big mess in neat rows...

Hope that helps you reconsider.

Cheers,

Julius