Permissions with status
Check current situation
For a long time, SAP authorization consultants and ABAP developers have disagreed on how to implement authorization object characteristics in the coding. There are two positions: On the one hand, consultants advise never to test for the signal word DUMMY, the constant space or the literal ' '. These tests only superficially check for the existence of an authorization object and do not react to settings in the field specification in the profile of the roles. Moreover, the literal ' ' is then authorized because it is displayed in the transaction STAUTHTRACE. On the other hand, there are situations where development uses these superficial tests to save the user time and the machine resources. If the program determines early on that the user does not have the necessary objects in the user buffer, it may abort before the first SELECT and issue an appropriate error message. Both positions contain a kernel of truth. Let's look at the effects of different programming on a simplified example. The role(s) have only the authorization object S_DEVELOP with the field value DEVCLASS "Z*".
Finally, the check logic provides for a row-level check within a table if you want to restrict access to the table contents depending on an organisational mapping. For example, if you want a user to view only the data from a table that affects the country where their work location is located, you must configure it accordingly. To do this, you define and activate organisation-relevant fields as an organisational criterion (see Tip 62, "Organisationally restrict table editing permissions"). To keep track of which users can access which tables, run the SUSR_TABLES_WITH_AUTH report. This report provides information about which user or single role has the S_TABU_DIS or S_TABU_NAM authorization objects. The result list shows all the authorised tables, their permissions, and their permission values.
User Interface Client Permissions
You can assign a Table or Care View to a table through the SE11 transaction or SE54 transaction. This mapping is defined as a customising setting and therefore remains in place after a release change. You can assign a table to a table permission group by using the SE11 transaction by selecting your table in the start image and pressing the Display button.
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
At "www.sap-corner.de" you will also find a lot of useful information on the subject of SAP authorizations.
If you want to add your own checks to standard applications, you must first find the appropriate place to implement the check.