Announcement:
wanna exchange links? contact me at sapchatroom@gmail.com.
Posted by
Admin at
Reply from R. N. Wilhite on May 17 at 9:12 AM First of all, I'd ask in the basis/security forum.
Second, I'd be thinking that one of several things. Your roles are too
granular. You are breaching SOD. Or, you have a special condition that
will require advanced coding techniques to overcome.
In the last case, as an example:
We needed for a person who was not allowed to change FICO documents to
change only a text on a FICO document. We ended up creating a process that
RFC'd as a super user to an FM that changed the text. That becomes legal,
because the user has no control of the action on the RFC side and no
knowledge of the password used to drive the super user.
Neal
| | | ---------------Original Message---------------
From: Rob Michaels
Sent: Thursday, May 17, 2012 8:08 AM
Subject: Accumulation of Access Permissions
Does anyone have examples of accumulation of access for permissions?
Here is one we had:
Problem is users might have authorized access to a transaction in a certain role e.g. VA02 change sales orders which also require access to object V_KONH_VKx with activity 02 Change. This user also has VK13 assigned via another role where activity is set to 03 Display. The combination of these 2 roles enable the user to switch to change mode in VK13 and maintain pricing conditions.
How does one eliminate the problem? Do you have to create a custom transaction ?
Thanks, |
| Reply to this email to post your response. __.____._ |   _.____.__ |
