Solved: Significance of s_user_grp

Former Member · ‎10-13-2009

Hello All,

I know that S_USER_GRP is an auth obj related to user maintenance. Recently while testing our roles I saw this auth obj in HR

Employee role and Employee delegate role.

What is this object doing here? Does this obj is needed for these roles, then in what way is it useful?

Also, while doing FI roles testing this auth obj appeared in trace when running a report transaction.

COuld anyone explain me and make this clear for me.

Regards,

Brahmeshwar

arpan_paik · ‎10-13-2009

Hi

S_USER_GRP is for user maintenance for several transaction like SU01, SU12 etc. To get the full list of these transactions go to table USOBT_C put the object S_USER_GRP and execute. You will get the list of transactions. If these transactions are required in the roles where you observe then you know why this object is present in that role. If these transactions are not required in HR or those FI roles (what should be) then this object need to be removed.

Arpan

arpan_paik · ‎10-13-2009

Hi

S_USER_GRP is for user maintenance for several transaction like SU01, SU12 etc. To get the full list of these transactions go to table USOBT_C put the object S_USER_GRP and execute. You will get the list of transactions. If these transactions are required in the roles where you observe then you know why this object is present in that role. If these transactions are not required in HR or those FI roles (what should be) then this object need to be removed.

Arpan

Former Member · ‎10-13-2009

Yes I know generally for what all t-codes s_user_grp is needed. My concern is that when testing a report transaction eg :

S_ALR_XXX for a FI role , I faced an auth issue and when i checked in the trace it is showing s_user_grp with RC12.

Is this auth obj needed to run these FI reports?

Regards,

Brahmeshwar

Former Member · ‎10-13-2009

Who built the HR roles? Do the objects contain activity 02? Are they added manually? If they are not manually added (which they shouldn't be unless documented) then you can use the "mountain" icon to ID the transaction they are linked to in SU24. You can run through those transactions with the functional team to see where the requirement comes from. Whoever built the roles will be able to tell you why they were added if they are manually inserted.

Lots of objects are checked during the execution of a transaction/report. Not all of them are required and S_USER_GRP does pop up from time to time. If you sit with a developer and look through the code for that report you will soon see where the check is invoked and the logic surrounding it.

Former Member · ‎10-13-2009

Thanks Alex.

The obj was pulled in from su24 when it popped up in trace while testing the FI report. The obj got actvt 3 and 5.

As you said, I may need to sit with developers.

Thanks for the suggestion.

But, why does trace does not show proper auth objs when running a FI report. Most of the time trace shows something else which is not needed?

Regards,

Brahmeshwar

Former Member · ‎10-13-2009

The trace returns the values for all the AUTHORITY-CHECKS performed and the relevant Return Codes. I suppose it would be possible to strip out the non-critical RC's but that wouldn't help if code is directed to do something based on a particular "non-standard" RC.

sdipanjan · ‎10-13-2009

You may need to look into the available SAP Notes related to S_ALR_* Tcodes and their corresponding Authorization checks. You may see a considerably large list.

FYI: Though S_USER_GRP is used to check Users authorization time to time but it doesn't mean that these checks are relevant only for SU* TCodes related to User admin. In so many cases a Program (rather say Include) contain a this object to check users auth.

Regards,

Dipanjan