Question:
I have added the field for release code to the org level so that I can make use of derived roles, but although the release codes are in the org level they do not pull through and as soon as the mother role is generated it overwrites the objects's values.
The KOSTL and ESG that I put in works, but this does not want to.
Please advise
Answer:
Hi
If you have maintained the authorization value directly in pfcg without using the "Define organization levels..." or the Organizational level push button, the organizational will not "pull through" - only maintain organizational levels using the "organizational level" button, unless you really want to bypass the inheritance of organizational levels from the mother role.
Regards
Morten
Answer:
What I did was:
Created the mother role with * in org level for Release codes.
In the derived role I added the correct values in the org level - when generated the correct values are added to the object.
When you generate the mother role to update all the child roles, the values in the child role is overwritten with *.
Answer:
Hi Koekie,
You should be able to get around this problem by entering a dummy value (eg. X) instead of a * for the org variable in the parent role.
Only problem is, you cannot assign the parent role directly to a user. It is simply there as a basis for creating derived roles.
The risk of maintaining parent-child role relationships in this way also needs to be well documented and communicated to Security Administrators.
Hope this helps.
Dorsal.
Answer:
Koeke,
In relation to my previous note, I should have elaborated more on the purpose of using the dummy value for the org level field variable in the parent role.
Ordinarily, entering a * as a value for the org level field variable in the parent role should not overwrite the values you have entered in the child role when the child role is adjusted from the parent role. Org level field variables are supposed to enable differences between the parent and child role for the organisational fields in question.
Entering a * in the parent role, however, becomes a problem when an authorisation needs to be split.
Supposing there was the following requirement for a role:
M_BEST_WRK (part 1) - change site ABCD only
ACTVT 02
WERKS ABCD
M_BEST_WRK (part 2) - display all sites
ACTVT 03
WERKS *
If, in the parent role, a * was entered for the $WERKS org level field variable, then you wouldn't be able to break up the change and display activities in the child role. Entering a dummy value for the org level field variable that you wish to maintain in the child role, however, affords more control. Your parent role would therefore look like this:
M_BEST_WRK (part 1) - change site X only - where X is the value to be entered in the child role org level field variable
ACTVT 02
WERKS X
M_BEST_WRK (part 2) - display all sites
ACTVT 03
WERKS *
Your issue with release codes and release groups is different because auth object M_EINK_FRG cannot be split. However, I just thought I'd clarify my point....
Regards,
Dorsal.
Answer:
Dorsal wrote:
"Entering a * in the parent role, however, becomes a problem when an authorisation needs to be split. "
To elaborate on what Dorsal said, if you split auths (enter one object twice) and then put a "hard" asterisk in a field normally filled from the Org. Levels, you better remember *never* to Merge Authorizations for that role! SAP does not distinguish between "hard" (manual) and "soft" asterisks (such as the ones you normally put in the parent role, that will be overridden in the children by the org. levels you maintained in each child.) I learned this one the hard way. Your special, global authorization (your hard asterisk) vanishes as it is merged into the "soft" one in the parent and your users lose their global access.
Example:
Parent role has split auth for F_SKA1_BUK.
F_Ska1_buk
Activity 03
Co. Code * (hard/dark blue)
plus
F_Ska1_buk
Activity *
co.Code * (soft/fills from org. levels in derived roles)
so the user with a derived role can view all company codes but only change their own.
If you Merge Auths for this role, these two objects merge as follows:
F_SKA1_BUK
Activity *
Co.code * (soft/fills from org. levels)
The global view auth. is merged out of existence. Gotcha!
Thanks, Dorsal, for the dummy value suggestion! I will definitely try that!
(It is also possible to leave the field yellow if you can stand to look at it--I can't!)
Mary