Add New Organisation Levels
System trace function ST01
After the functional specification has been removed, the implementation can begin: To do this, first create your custom authorization object and implement the permission check provided. The next step is to maintain the SU24 transaction proposal values for the respective customer transaction. To do this, call your custom-created transaction and assign the necessary authorization objects either manually by using the Object button, or use the Permissions or System Trace to assign the permissions (see Tip 40, "Using the Permissions Trace to Determine Custom Permissions Proposal Values"). You must leave the authorization objects used in the customer's own coding. For each authorization object, you can maintain field values that appear as suggestion values in the respective roles. Now all the roles concerned must be adapted. If the mixing mode for the transaction PFCG is set to On (see tip 38, "Use transactions SU22 and SU24 correctly"), all PFCG roles assigned to the transaction in the role menu will be recognised and can be remixed via the transaction SUPC. If the customer's transaction is not yet in the PFCG rolls, it will be added here and the respective PFCG role will be remixed.
Once you have logged in, the permissions associated with your user (via the user account) will be available. Each of your actions leads to the use of runtime versions of the corresponding objects. This also applies to every privilege and role. Runtime versions of rolls are not transportable in SAP HANA. However, in order to achieve a high quality in the development of your applications, you should use a system landscape with development system (DEV), quality assurance system (QAS) and productive system (PRD). To enable you to translate development results to QAD and PRD, SAP HANA Studio provides you with the opportunity to create objects in a (freely definable) Design Time Repository that you can provide and transport via Delivery Units to other systems.
Default permissions already included
The Permissions check continues again if the table in question is a client-independent table. This is done by checking the S_TABU_CLI authorization object, which decides on maintenance permissions for client-independent tables. For example, the T000 table is a table that is independent of the client and would be validated. To enable a user to maintain this table by using the SM30 transaction, you must maintain the S_TABU_CLI authorization object, in addition to the table permission group or specific table, as follows: CLIIDMAINT: X.
As part of identifying authorization problems, it should be documented what the risks are if the current situation is maintained. Often, those responsible in the company do not want to make a correction because it causes costs and work. If the current concept works and security gaps are abstract, many people in charge are reluctant to change anything. For these reasons, the first step should be to document what problems and dangers lurk if the current concept is not corrected: First, the risk of fraud, theft, and data privacy and security breaches increases. Documentation can help identify where dangers lie. There is a fundamental problem of financial damage to the company if action is not taken. Another danger is that users will experiment with their authorizations and cause damage that can be avoided by having a clean authorization structure. Also a problem is the increased administrative overhead of granting and managing permissions. The effort increases if the current role assignments are not transparent and optimally structured.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
The freeware Scribble Papers puts an end to the confusing paper chaos. The tool is also suitable for storing, structuring and quickly finding text documents and text snippets of all kinds in addition to notes.
As part of identifying authorization problems, it should be documented what the risks are if the current situation is maintained.
In the FIORI environment, there are basically two different types of access via a tile.