There are a number of authorization objects that run into errors in almost every SU53 and often in the authorization trace, but in the end are almost never the cause of the problem. Today we’ll show you which objects these are, when you can ignore them – and when it’s actually worth checking them more closely.
There it is again: that one email from the business department. “We cannot execute transaction XY. Please adjust the permissions!” In the best case (if you have already annoyed your colleagues often enough), the SU53 excerpt is attached to the mail. It shows errors for various authorization objects. But where do you start now?
Some of these objects can be ignored in most cases (but not in all!), because they are rarely the cause of the problem:
P_RUNTIME
The object P_RUNTIME is only relevant when it comes to SAP Screen Personas. This is a software addon that allows users to personalize their SAPGUI interfaces.
Similar to FIORI, transactions can be combined and also supplemented with additional data, images or buttons. The individual elements such as buttons etc. can be rearranged or even hidden. In addition, SAP Screen Personas can be used to include not only classic transactions but also, for example, WebDynpros developed in-house in the personalized interfaces. In this way, the applications should be clearer for end users and thus quicker to grasp and easier to use. This reduces training and support costs.
The interfaces are customized using themes and flavors. You authorize their use and design with the object P_RUNTIME. The fields Activities for Framework (P_ACTVT_FW), Runtime Activity (P_ACTVT_RT) and Concrete Transactions and Screens (P_APP_ID) are available for authorization.
Now it may be that SAP Screen Personas is in use in the company, but is not available for all roles/every user. If users with authorization errors come to you who do not (should not) use SAP Screen Personas, P_RUNTIME runs in their authorization check for errors, but is irrelevant for your analysis.
S_GUI
The S_GUI object appears frequently in SU53. You use this object to control the permissions for downloading and uploading data. This is relevant, for example, if lists from SAP are to be further processed in data processing programs such as Excel. S_GUI is also usually necessary for migration projects. Above all, users need a specific version of this object to copy and paste SAP lists into other applications or windows.
The object has only the field Activities (ACTVT) and can be defined there as follows:
- 60: Upload (Import)
- 61: Download (export)
- 02: Clipboard (relevant to copy and paste data)
- 04: Print
Note: S_GUI with ACTVT 02 is needed in most cases. All other error messages are only relevant if the users actually want to import or export data.
S_ALV_LAYO
You use this object to control whether users are allowed to change standard layouts of the ABAP List Viewer (ALV) that apply to all users. For example, you may then decide system-wide, i.e. for all users, which fields of a table are to be displayed by default, and so on. In most cases, this authorization is reserved for developers/administrators only, for good reason. Nevertheless, the object appears in many authorization checks – and runs into errors accordingly. If the affected user is not exactly a developer/administrator who wants to make exactly these adjustments to the default layout, you can ignore the entry in SU53.
Good to know: The object only controls the change authorization for overarching standard layouts. Even without these permissions, users can change the table and list layout for their own user at any time.
Good to know II: Administrators who are to be allowed to adjust the standard layout need ACTVT 23 in object S_ALV_LAYO. If problems still occur with this (for example, when saving the changed standard layouts), please contact the basis/application developer, because then settings for the parameters in the method set_table_for_first_display may not be correct (e.g. i_save).
S_ALV_LAYR
Similar to S_ALV_LAYO, the authorization object S_ALV_LAYR also appears from time to time in authorization error logs. It also controls the change authorization for cross-user ALV layouts, but limited to concrete reports. Therefore, in this object, you must not only define the ACTVT (23 for “maintain”), but also the Report Name (REPORT), Administration ID (HANDLE), and Logical Group (LOG) fields.
Again, this is the case in most organizations: Maintenance authorization for cross-user report layouts is reserved for administrators and developers.
If you can exclude the above-mentioned authorization objects, often only functional authorization objects remain in SU53. You still have to check them individually, but the effort is nevertheless significantly reduced. Good luck!