View system modifiability settings
RS_ABAP_SOURCE_SCAN
This very critical authorization can be used to electronically erase, or manipulate program runs including authorization queries in a variety of ways. This authorization should be assigned only very restrictively, for example developers need the authorization however for their daily work.
Add SAP Note 1433352 to your system. This note ships with the RSAUDIT_SYSTEM_STATUS report. This report documents the current status of the Client and System Modification Settings in an overview, which you can also print out for evaluation if required. The advantage of this report is that pure display permissions are necessary to execute it.
Change management
When accessing tables or views, the S_TABU_DIS authorization object is used to grant permission for a specific table permission group in the permission check. Note in this context also Tip 73 "Use authorization objects for table editing" and the S_TABU_NAM authorization object presented there. You can create table permission groups by using the transaction SE54 or by using the V_TBRG_54 care dialogue. They fall under the customising and can only contain four characters until SAP NetWeaver 7.31 SP 2. To create a table permission group, call the SE54 transaction and select Permissions Groups in the Edit Table/View pane. The Create/Modify button provides an overview of the existing table permission groups. For example, this way you can also change the name of a table permission group. In the Table Rights Group overview, click the New Entries button to create a new table permissions group. Give a name for your permission group and a matching name. After you have saved the new entries, your custom table permission group is created.
You can do this by using the P_ABAP authorization object to override the usual permission checks. This applies to all reports that access the logical database PNPCE (or PNP). In case of a P_ABAP permission, the usual checks for authorization objects, such as P_ORGIN or P_ORGINCON, will no longer take place or will be simplified. This also applies to structural permissions. Whether the permission checks are simplified or completely switched off is controlled by the COARS field of the object. To disable all checks, set the value COARS = 2. This value does not limit the data displayed in the legitimate report. If you want to allow advanced permissions for reporting, but you do not want them to be unrestricted, you must select COARS = 1. In this case, you will also designate the P_ORGIN (or P_ORGINCON, P_ORGXX and P_ORGXXCON) authorization object. However, you must be careful not to mark all fields of the objects, otherwise direct access is also possible. Therefore, always write two versions of the P_ORGIN authorization object, one with the functional permissions (permission levels, info types, and subtypes), and one with the organisational boundaries (personnel area, employee group, employee group, and organisation keys). In addition, you will of course need a P_ABAP for the relevant reports with the value COARS = 1.
However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".
Trace after missing permissions: Run the System Trace for Permissions (ST01 or STAUTHTRACE transaction) to record permission checks that you want to include in the role (see Tip 31, "Optimise Trace Evaluation").
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
Here you also decide whether and how the tables can possibly be maintained in the productive system.