You do not have to use derived roles and it is often sensful to have central role administration, but if you want to go this route then you can use two controls:
- Via the role name you can control on S_USER_AGR which roles can be entered in change mode. Note that your role naming must take this into consideration as masking (*) is wildcarded from the first asterisk onwards.
- Via S_USER_VAL you can control which fields can be maintained for which objects. As org.levels are object independent, you might get away with * for the object and values for the field names. However take note that for different values for different field names you will need to insert different authorization instances of S_USER_VAL into the role. Complex combinations can cause collisions and you need to consider that if the org. values need to change often, then you need an org. structure naming convention to define the roles for the auth admins, otherwise you will be maintaining their roles a lot as well to add the vaues to S_USER_VAL so that they can add the values to their S_USER_AGR roles as well.
Most customers find central role administration a more reliable and systematic approach as maintaining an authorization concept in a good way is actually a specialized task. For example, the decentral admins might also change fields with "standard" status or maintain the org. fields in teh authorizations tab interface instead of via the org. level dialog.
My 2 cents 😉
Julius
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.