Use usage data for role definition
Note the effect of user types on password rules
If you want to allow users to access only individual table rows, you can use the S_TABU_LIN authorization object, which allows access to specific rows of a table for defined organisational criteria. A prerequisite for this type of permission is that the tables have columns with such organisational values, such as the work, country, accounting area, etc. You must now configure these organisational values in the system as organisational criteria that represent business areas; serve as a bridge between the organisational columns in the tables and the permission field in the authorization object. Since the organisational criteria are found in several tables, this eligibility check need not be bound to specific tables and can be defined across tables.
If you want to understand how to run a permission check in your code, you can use the debugger to move through the permission check step by step. To implement your own permission checks, it may be helpful to see how such checks have been implemented in the SAP standard. In this tip, we show you how to view the source code of permission checks using the debugger in the programme, or how to get to the code locations where the permission checks are implemented.
SAP Authorizations - Overview HCM Authorization Concepts
A new transaction has been added to evaluate the system trace only for permission checks, which you can call STAUTHTRACE using the transaction and insert via the respective support package named in SAP Note 1603756. This is a short-term trace that can only be used as a permission trace on the current application server and clients. In the basic functions, it is identical to the system trace in transaction ST01; Unlike the system trace, however, only permission checks can be recorded and evaluated here. You can limit the recording to a specific user. You can also use the trace to search only for permission errors. The evaluation is similar to the evaluation of the system trace in the transaction ST01. In transaction STAUTHTRACE, however, you can also evaluate for specific authorization objects or for specific permission check return codes (i.e. after positive or negative permission checks). You can also filter multiple entries.
To make the most of the time stamping process, you should fill the time stamp tables in the legacy system before upgrading. Implement SAP Note 1599128. With this correction, the report SU25_INITIALIZE_TSTMP is delivered, which allows to write the current timestamps of your data from the transaction SU22 into the respective timestamp tables USOBT_TSTMP and USOBX_TSTMP. After the upgrade, you will have a reference date for your SU22 data, which you can use to compare with the SAP proposal data shipped for the new release. Setting the timestamps in the legacy release reduces the effort required to complete step 2a, because only those applications whose SU22 data has been modified are matched. If you have not filled the timestamp tables in the old release, the tables in your new release will be empty. In this case, in step 2a, the content of the SAP proposal values will be compared to the customer proposal values, regardless of a timestamp.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
In order for these FIORI apps/tiles and groups to be displayed, the corresponding authorizations must be made on the basis of a group and catalog assignment.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
This list in the AGR_1252 table contains both the organisational fields that are shipped in the standard and the fields that you have collected for organisational fields.