Conclusion
Copy values from the Clipboard to the transaction's PFCG permission fields
Confirmation of the dialogue will immediately start the recording; They therefore end up in the PFCG transaction. We want to record the creation of a single role derived from a reference role. Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered. Enter the name of the derived role - we can influence it later when playing with eCATT - and specify the role. Now assign the reference role. Note that the PFCG transaction is actually executed, so the role is actually created in the system! In the SCC4 transaction, first check whether eCATT is allowed to run. Then start the SECATT transaction. As you get started, you can define and modify test scripts and test configurations. First, create a test script. Think of it as a blueprint or a flow rule for how to create new derived roles. The test script will contain your recording later. Give the script a talking name, such as Z_MASSENGERATION_DERIVATIVES. Then click the Create Object button. You will now go to the Attribute tab, where you specify the general frame data. Then click the Editor tab. Now it goes to the recording, in the eCATT language called patterns. Click the Pattern button and specify that you want to record the PFCG transaction by selecting the UIAncontrol and TCD (Record) settings. The system will propose to call the interface "PFCG_1"; You can simply confirm this.
The handling of organisational levels in PFCG roles wants to be learned. If these are maintained manually, problems arise when deriving rolls. We will show you how to correct the fields in question. Manually maintained organisational levels (orgons) in PFCG roles cannot be maintained via the Origen button. These organisational levels prevent the inheritance concept from being implemented correctly. You can see that organisational levels have been maintained manually when you enter values via the Ormits button, but the changes are not applied to the authorization object.
Check for permissions on the old user group when assigning a new user group to a user
You assign a reference user to a dialogue user by registering the reference user for additional rights in the SU01 transaction on the Roles tab in the Reference User field. If you are using Central User Administration (ZBV), the assignment applies to all connected systems. If the reference user does not exist in one of the systems, the mapping is ignored. However, the use of reference users also creates risks. This makes it easier to summarise permissions because it is difficult to keep track of the assigned permissions. In SAP NetWeaver AS ABAP 7.0 and above, reference users are considered in the reports of the user information system.
You have an organizational structure that includes 4 hierarchical levels - authority, department, unit, functional area). The authorization concept in your organization states that access (processing) to Records Management objects should be allowed for an employee only within his/her own organizational unit. However, the authorization check should only take place on three levels. So if a unit is subdivided into further functional areas, all employees of the unit and the functional areas should have the same authorizations. Since department 2 and department 3 work very closely together, employees of department 2 should be able to read all files, transactions and documents of department 3 and vice versa.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
The goal is for SAP SuccessFactors users to maintain an overview of roles and authorizations in the system.
A developer should not rely on the functionality of the SE97 transaction and therefore should include the possible permission checks in the code.