Master roles

Question: I am new to SAP and have my first question. Is there a way to look at a master role and tell which other roles derive from that role.I am making a change to the master role and I know that it makes the change to the roles that derive from it, but I also need to transport the roles that I change. If anyone has any help I could use it.
Thank you in advance for all you help.

Fred D

Answer:
The simplest way is to SE16 view table AGR_DEFINE and enter the master role in the parent field and list the child roles.

Do note: to get some of the changes to take place in the child roles you will have to user the "Shove the change to the child" pull-down menu path which may wipe out an subtle changes you made in the child that are not in the org level maintenance screen... One of the downfalls of derived roles...

Answer:
The answer to John's concern is don't make any changes to the child role that are not org level changes. Everything else is contrary to the purpose and intent of a child role. That means everything else.

Answer:
Hi Fred,

It depends on your naming convention really. Hopefully the simplest way in your case isn't to look at AGR_DEFINE. Always put the derived organizational values last in the name of the role. In that way you can use the the "mass transport" function (ctrl+shift+f6 when standing in PFCG).

Fx. if you got the following roles

FI_CASHMANAGEMENT
FI_CASHMANAGEMENT_01
FI_CASHMANAGEMENT_02

you can just transport FI_CASHMANAGEMENT*, and all the above roles will be transported.

/Blast

Answer:
Why bother.? SAP already transports dependent roles when it does a transport.

Answer:
Yes when you transport a derived role, the master role is always transported as well. But when you just transport the master role, then the derived roles will not get transported unless stated.

/Blast

Answer:
You can use more than one wild card in a selection field.

Answer:
The answer to John's concern is don't make any changes to the child role that are not org level changes. Everything else is contrary to the purpose and intent of a child role. That means everything else. But this requres a process that will have to outlive the creator and has to survive the back fill who may not have the discipline and understanding to ensure a child role (which is not apparent unless you look at the field at the bottom of the screen indicating there is a parant) is not changed "incorrectly" by the process's definition and who's sole goal it to "make it work".

Furhter it can cause a proliferation of one-off roles to make the access to work so as not to "change" the child..

Answer:
Baloney! We do process all the time in security. If you can't do process then you don't have security. If the process says that the child roles must be functionally identical to the master roles then anyone who changes the child role functionally will eventually pay the price. The role won't work.

That is called

"working as designed"

Stupid actions have predictable consequences.

Answer:
The key to successful Security implementation is to SIMPLIFY and minimize processes and not create extra process and additional things to remember. KEEP IT SIMPLE!

Just because SAP provides functionality does not mean it needs to be used. Most of the bells and wistle funcionality is to bail a customer out because of poor design and the need to go live "tomorrow".

Answer:
Stupid actions have predictable consequences.

I disagree.
Sometimes nothing happens.
At other times something happens but no one notices.
All too often a whole bunch of sparcely documented (and therefore hard to predict) things happen in addition to the predictable ones and they can very often be traced back to someone who still thinks they are clever. The latter actions happen to people who are too clever as well and therefore don´t need to have their design tested by others, including the stupid ones.

But it is possible for the common denominators of the large and small and the thick and thin to protect both the stupid and the excessively intellegent from themselves by keeping things simple and the overview transparent for all with a bit of common sence and training to use consistently.

Derived roles and composite roles are a breach of common sence.
_________________