Permissions checks
Use table editing authorization objects
There are several ways to view the implementation of permission checks: Either you jump directly from the system trace for permissions to the appropriate locations in the programme code, or you go over the definition of the authorization objects. To view the permission checks from the permissions system trace, start the trace from the STAUTHTRACE transaction and run the applications you want to view. Now open the evaluation of the Trace. In the Programme Name column, you can see the programme that includes the Permissions Check. Double-click to go directly to the code site where the permission check is implemented.
First, consider the transport of your proposed permissions from various development systems to a consolidation system. When you save permission proposal values in transport orders, you will notice that generic entries are used instead of detailed BOMs. These generic entries mark all applications, for example, with TR*..
Introduction & Best Practices
Far more damage, however, can be caused by too extensive authorizations. For example, an employee may be authorized to access data for which he or she is not authorized. In the worst case, criminal activity can cause economic damage. To prevent this, an authorization concept must be in place that describes how authorizations are to be created and assigned to users.
Native or analytical tiles: These tiles work exclusively in the FIORI interface and are adapted to the new technology. Here, for example, push messages are displayed on the tile, or key figures, diagrams, etc. are displayed, which can then be processed directly with a click. These tiles do not have direct GUI access, or cannot be used directly in the GUI environment. As mentioned above, access to these tiles is provided in a so-called front-end system via corresponding catalogs and groups. However, the underlying conceptual permissions (who is allowed to do what within the functionality of the tile) follows the same processes as in the "old world" for transaction access. The tile in the front-end needs here corresponding dependent distinctive authorizations (keyword: SU24 adjustment). In the back-end system, then again - analogous to the "old" world - about a role, which is built in the profile generator and maintained on object and field level, or set. Of course, topics such as updating internal and third-party tools, integrating cloud solutions, modern hybrid infrastructures, defining and operating ongoing dynamic changes, etc. must also be taken into account here.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Finally, we would like to draw your attention to SAP Note 1781328, which provides the report PFCG_ORGFIELD_ROLES_UPD.
The permission checks, including the time period delimitation, are implemented in the logical database and work for all reports based on a logical database (e.g. the RAGITT00 grid is based on SAPDBADA and the RFBILA00 balance sheet report is based on SAPDBSDF).