Customizing
Translating texts into permission roles
You have developed applications yourself and would like to maintain suggestion values for them? The easiest way to do this is with the help of the permission trace. Permission checks are also performed on self-developed applications. These applications must therefore be included in the PFCG rolls. If they are maintained in a role menu, you will notice that in addition to the start permissions (such as S_TCODE), no other authorization objects are added to the PFCG role. The reason for this is that even for customer-specific applications suggestion values must be maintained to ensure that the PFCG role care runs according to the rules and to facilitate the care for you. Up to now, the values of customer-owned applications had to be either manually maintained in the PFCG role, or the suggested values maintenance in the transaction SU24 was performed manually.
Authorization tools are only as good as the person using them. Until now, no tool has made it possible to create ready-made authorization concepts with just a single click.
Use the authorisation route to identify proposed values for customer developments
The authorization check for the authorization objects PS_RMPSORG and PS_RMPSOEH runs as follows following a user entry: The system determines the organizational unit to which the user is assigned. Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy. The system determines the set (M1) of all organizational objects that are assigned to these organizational units. The system determines the organizational unit to which the object to be processed is assigned (corresponds to the lead organizational unit in the attributes of the object to be processed). Starting from this lead organizational unit, the system creates a list of all organizational units that are superior to the determined organizational unit within the hierarchy. The system determines the set (M2) of all organizational objects assigned to these organizational units. The system forms the intersection (from M1 and M2) of the matching organizational objects of the user and the object to be processed. The system determines the organizational levels that match for the user and the object being processed. Once a matching organizational level is found, the system performs the authorization check for the other fields of the authorization object (e.g., type of object or activity); if the system cannot determine a common organizational level, processing is rejected. If the user is allowed to perform the requested activity, processing is allowed; otherwise, the system rejects processing.
Suggested values are maintained in the transaction SU24 and delivered through the transaction SU22. Read more about the differences between these two transactions. Maintaining suggestion values via the SU24 transaction is useful if you want to reflect your own requirements or if the values provided by SAP do not meet customer requirements (see Tip 37, "Making sense in maintaining suggestion values"). These proposed values form the basis for the role maintenance credentials in the PFCG transaction. As you know, the suggested values provided by SAP are in the transaction SU22, which are delivered during reinstallation or upgrades as well as in support packages or SAP hints. What is the difference between transactions and how are they used correctly?
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
Package Privileges permissions: Package Privileges are permissions that control access to development packages in the SAP HANA database.
If you want to allow users to access only individual table rows, you can use the S_TABU_LIN authorization object, which allows access to specific rows of a table for defined organisational criteria.