derived roles

[Former Member]

All,

I have a question regarding the authorization for the derived roles.Say for example you are combining two derived roles from the same master role role1: z_der_plant100 and role2 :z_der_plant200.Now role1 has only create option for plant 100 and role2 only change option for plant200.If we combine both the roles and assign it to user,will user get access for create,change to plant 100 and create,change to plant 200??

[Former Member]

If you have 2 roles from the same master role, then you should not have create on one, and change in another.

At least, that is my understanding of what (correct use of) derived roles are intended for.

Cheers,

Julius

[Former Member]

OK,your correct.1) lets keep the same example and instead of create and change sepaartely , both the role1 and role 2 has create as well change option for palnts 100,200 respectively.In case if we combine both the roles(role1+role2),at this point user will have access for create ,change for both the plants(100,200)?

2) adding va01 to two different roles role A-plant 100,role B-plant 200.role A is restricted with 01 and roleB is with 02.Now combining both the roles to a user gives access to 01 and 02 for both the plants(100,200)??

[Former Member]

Hello Kevin,

To your questions:

1) Yes, if that is what the roles can independently do, then that is also what a user with both roles can do.

2) If I remember correctly, VA01 = Create Sales Order. If I also remember correctly, that is independent of "Plant" authorization objects. So in all cases (one role, both roles, or no role), it will have no effect.

Or is this just a matter of principle question?

Cheers,

Julius

[Former Member]

My own thinking what will happen if we combine so and so roles....

I have a other basic question regarding the field values of a A.object.As we know the one particular A.object is related to so many T.codes.Eg:assigning just 1 tcode to a role which contains 5 A.objects(those 5.A.objects are related to so many different T.codes).If we generate the profile for the role it will bring up all the mandatory field values for that specific T.code which is added.Suppose if we assign some values in the fields which are blank(maintain) or even changing the standard values(01,02 standard but deleting those values and assigning 03,04).Will the user gets accesss for the maintained/changed field values ? The reason for asking is ,as we are deleting the mandatory field values of the tcode and assigning some other values which are standard values for some other Tcodes (which are not added in the menu)

Pls excuse me if it confuses ....

[Former Member]

Hello Kevin,

Yes, you have confused me.

I think that you would also be confusing the system you are working on and anyone else who would need to do any maintenance on those roles in future.

If you clearly document the manual entries (those which differ from the SU24 proposals, and org level fields for which you have manually added objects which don't belong to the transactions), then it would help somewhat.

How this relates to derived roles, VA01 and plant is still beyond me.

You would also confuse any SOD analysis based on tcodes and role to role comparisons also at application object level to no end - not that such confusion is difficult to create anyway.

Cheers,

Julius

[Former Member]

Sorry about that..actually am practising in sand box. Is the change in su24 settings will affect the usobt_c table or usobt table?? We are copying the customer table from usobt and all the authorization object for pfcg is pulled from customer table??

[Former Member]

Even sandboxes have feelings...

Which release is your sandbox on?

Yes, you should transfer the SAP defaults from Su22 to Su24 using step 1 in Su25, then maintain your data there using Su24; if you are going to maintain it... (otherwise it will be wiped out when someone else on a higher release wants to maintain your roles. Which will confuse them...)

In the case of derived roles, this might be different and certainly more complex. So if you confuse the master role... then what the derived roles will do is a black-box for me.

I would say, an all round bad idea.

Cheers,

Julius

[Former Member]

Hi Julius,

You have mentioned that "If you have 2 roles from the same master role, then you should not have create on one, and change in another." Can u please explain this one why we should not have create on one and change in another?

Regards,

Sandhya

[Former Member]

Hello,I think what Julius is trying to say is ,as the derived roles are from same master roles they will be having same kind of authorization in all derived roles.

[Former Member]

I have only seen sensefull use of derived roles when there was limited functionality required accross many company codes, where the users in the company codes required exactly the same functionality which is easy to use and no sense in expanding on with fancy reporting requirements etc. Even with only a handfull of transaction codes and about 10 objects in total... there were still some problems with lack of flexibility, and with time the security relaxed.

Perhaps in more complicated use cases, which would be more problem prone, there is a way of doing what you have described. But to my knowledge, this is not the intended use of derived roles which are identical to the master (except for organizational data).

Cheers,

Julius

[Former Member]

>

But to my knowledge, this is not the intended use of derived roles which are identical to the master (except for organizational data).

Correct. Never use derived roles unless are differentiating only on Org Level fields. There are far too many risks & I have seen it so many times when someone has inadvertently pushed down changes and wrecked everything

Edited by: Alex Ayers on Feb 16, 2008 12:01 AM

[Former Member]

Hi Alex, Julius,

Thanks a lot for your information.

Regards,

sandhya

[Former Member]

I agree with Alex.

As per my knowledge derived role concept will give strong security levels, and it is usefull to avoid sox conflicts.

concept -> when we derive a role, both the roles (i.e master & derived) should have same access data. Only Org. values will differ.

this way we can restrict users at position wise and org. level.

if you want more details, let me know.