Equal permissions
Evaluation of the authorization check SU53
The context-dependent authorizations combine the general and structural authorizations and avoid situations like in the example above. The context-dependent authorizations can be separated so finely that a separation of functions can be made possible without any gaps. Basically, with context-dependent authorizations, the authorization objects are supplemented by structural authorization profiles. This means that authorizations are no longer assigned generally, but only for the objects in the authorization profile. The use of context-dependent authorizations means that the familiar P_ORGIN authorization objects are replaced by P_ORGINCON and P_ORGXX by P_ORGXXCON. The new authorization objects then contain a parameter for the authorization profile.
To create a authorization object, you must first select the result area and the form of the result invoice, whether calculating or accounting, for which you want to validate the authorization object. To do this, you must enter the name of the authorization object to be created and click the button (Next). You then set a text for the authorization object and select a maximum of ten permission fields for the object using the Fields button. Only a selection of the characteristics defined for the result area - and for the calculation of the result account also the value fields - is possible. You can now create different authorization objects for the key numbers and characteristics, or you can group the relevant fields into a authorization object. We advise you to define only one object with all relevant fields, as this will facilitate the maintenance of permissions. In our example, we created an accounting authorization object for the characteristics of the profit centre, distribution channel and work in the information system.
Determine Permissions Error by Debugging
By correcting SAP Note 1692243, you can now also use the report in a ZBV (Central User Management) environment; It is no longer limited to individual clients. If the role assignment of the ZBV in the SCUM transaction is set to global, it is sufficient if the correction is recorded in the central client. Then it is only possible to execute the report in the central client. Furthermore, you have the option to select the ZBV's subsidiary systems from the Receive System drop-down box in such a way that only the systems in which the role assignment is to be consolidated or deleted are taken into account. In the results list of the consolidated role assignment, you will now be listed in the ZBV-System column the subsidiary systems where consolidation or deletion took place.
Users of your Web applications should have access to the applications that correspond to their particular business roles. You can use the S_START authorization object to map this request in the PFCG roles. Applications based on SAP products offer users different access methods, of which the use of SAP GUI with application-related SAP transactions is to be called "classic". In Web applications, application interfaces are represented in a Web browser. Not only transactional processes, but also the display of results from data analyses or static facts should be supported. The SAP transaction model, which controls access through the S_TCODE authorization object, does not meet these requirements.
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.
Depending on the type of privilege, you will be presented with the appropriate details by selecting an entry.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
The call to your implementation of the BAdIs is the last step in the process of storing user data.