topic Re: Authorization object conflicts in a user profile in Application Development and Automation Discussions

Authorization object conflicts in a user profile

Former Member — Fri, 30 Oct 2015 13:48:48 GMT

We have a requirement where we need to maintain different values of the same authorization object in two different roles for the same user.

The requirement is for a user to have ability to display all views but to be able to change only type (V).

For example we have roles as below.

Role 1 : Z:_MM02

Auth Object : M_MATE_STA

ACTVT 02

STATM V

Role 2 : Z:_MM_DISPLAY

Auth Object : M_MATE_STA

ACTVT 03

STATM *

So when we are assigning Role 1 and Role 2 to user A the restriction on first role is getting bypassed, means the user

is able to go to MM02 to change any views. How to handle situations like this ? Any thoughts or inputs would be appreciated.

Re: Authorization object conflicts in a user profile

Former Member — Fri, 30 Oct 2015 15:01:48 GMT

Hi, are you sure that the user isn't getting this from somewhere else?

Role 1 + Role 2 will (in your example) give display/03 all and change/02 only V, the authorisations will not combine to give change/02 for *. That is not how the authorisation concept (in ECC) works.

Re: Authorization object conflicts in a user profile

Former Member — Fri, 30 Oct 2015 16:23:40 GMT

Thank you for your response Alex.You are right,the user is getting it from another role which has authorizations like this.

Role 1 : Z:_MM02

Auth Object : M_MATE_STA

ACTVT 02

STATM V

Role 2 : Z:_MM_Processing

Auth Object : M_MATE_STA

ACTVT 02

STATM *

So now suppose in Role 2 if I change ACTVT to 03 then the problem would be fixed (I tried that already) but my question, is there any other way to do it without changing the ACTVT to 03 for Role 2 ? We need to have ACTVT 02 for Role 2. So what can I do about it?

Re: Authorization object conflicts in a user profile

Former Member — Mon, 02 Nov 2015 13:47:10 GMT

Hi, as you have identified, the problem is the Z:_MM_Processing role so that is the one which you should be amending. In this case restricting the STATM values to the ones required. From the look of the title of the role it's likely designed to give access to all material status so a more restricted variant is needed if that is a key control requirement for you.

Cheers

Re: Authorization object conflicts in a user profile

Former Member — Mon, 02 Nov 2015 14:01:09 GMT

Thanks for your input Alex.