SUIM DISPLAY

[Former Member]

Any/All,

I am trying to secure SUIM access for Managers by division. I created a master roles and then created derived roles and secured it by auth obj S_USER_GRP. When I go to test the role, I am still able to see users from other divisions. Am I missing something.

Thank you very much in advance.

[Former Member]

When you run a trace on the report, is S_USER_GRP checked?

[Former Member]

Alex,

I ran a trace on my execution and it is pulling a user group that I did secure it by. I secured it by our Bronze Division but it show that it is pulling the user group Corp It. How does this happen?

[sdipanjan]

What are values did you change for the authorization objects associated with SUIM in Master and Derived roles?

There should not be any difference in authorization for SUIM in Master and Derived roles. There is no such field available to manage access against Division ( $SPART ) in S_USER_GRP. You can use "User group in user master maintenance" (CLASS) to provide segregation for User administrator. Plz go through the documentation of the Object to get details.

Regards,

Dipanjan

[Former Member]

Dipanjan

In the Master role for S_USER_GRP I inserted a star in the class and in the derived role I inserted the user group that I created in SUGR. I have been doing security for a while and you miss understood my response. I want to create a derived role for each of our divisions and I am NOT managing access against division. I am providing just SUIM access to managers for their different divisions.

Edited by: Daisy Jayrajh on Jul 16, 2009 4:25 PM

[sdipanjan]

> In the Master role for S_USER_GRP I inserted a star in the class and in the derived role I inserted the user group that I created in SUGR. I have been doing security for a while and you miss understood my response. I want to create a derived role for each of our divisions and I am NOT managing access against division. I am providing just SUIM access to managers for their different divisions.

Still the concept is Wrong! Master-Derived role concept came into picture to minimize the effort of creating many roles with exactly same authorizations and differentiating only with the organization level values. In S_USER_GRP there is no Organization Level field exists. So the way you want to separate access for Managers is not correct and will not be of help for future maintenance.

You can try with the following approach:

Create different user group for Users of different Location but this should be same for all users of same Location. For e.g. User grp US_Enduser for all users of USA ; UK_Enduser for all users of UK.

Assign this user grp to corresponding manager's S_USER_GRP: CLASS field together with ACTVT = 03 , 08. Don't create Derive role. Just copy the roles from one into another and change the Field CLASS as mentioned. Also make sure to provide only 03 & 08 activity for all activities associated for objects S_USER*.

Regards,

Dipanjan

Edited by: Dipanjan Sanpui on Jul 16, 2009 4:39 PM

[Former Member]

Thank you very much. I will try this concept.

[Former Member]

I tried creating single roles and restricted the class and it still does not work. It is allowing me to view users that belong to other user groupls. I will work with it some more and if I cannot get it working, then I will open a ticket with SAP.

[Former Member]

Jay,

Did you checked the user access to object S_USER_GRP.If you mentioned any user group name in CLASS field then there is no way that you can display users in other user group.

May be S_USER_GRP is being pulled from other role or profile?

[Former Member]

Yes, S_USR_GRP is pulled from the Common role that has SU3. I just checked. How can I work around this or is there a work around for this>

Thanks for bringing this up.

[sdipanjan]

You need to maintain same value for all the Instance of S_USER_GRP in the role to get the result I described in my other post (process description). Hope this will help you to get the desired result.

Also make sure that the Manager is not getting any other value for CLASS of S_USER_GRP through any other role.

Regards,

Dipanjan

[Former Member]

SU3 does not need S_USER_GRP because it is your own data, so that is incorrect.

Also note that you need to have the same group name from SUGR assigned to the user ID's themselves, otherwise this is not going anywhere... (just incase).

However I don't think that you will be able to achieve this completely anyway. I have tried and was not successfull.

Cheers,

Julius

[Former Member]

Thank you Julius, those tips were very helpful.

[Former Member]

I did however recently here that there was a general clean-up of the checks in the selection screen helps going on and this could be expected to generally include the user information system as well, so keep an eye on note corrections.

To my knowledge this was tolerated as the user must already have some display authority for a group as could be expected for SUIM. It just did not matter which one.

Cheers,

Julius