SU24 Tips & Tricks – How to authorize forward navigation from list reporting
The first four blogs dealt with fields which you should and respectively should not maintain as SU24 proposals for roles. Then also those fields which you cannot maintain which are dealt with in the 3rd blog. The 4th blog dealt with creating instances of authorization objects within single roles instead of single role instances in composite roles. This simplifies your concept and gains better control over the maintenance of roles.
You will have reached 99.5% field value completion of your roles and have where-used-lists references to all objects in the menu. That allows you to exactly see why it is in the roles and what will happen for the user if it is not in the role. You are already in control of your authorization concept from a maintenance perspective of the roles.
But there are always a few special cases and special requirements in reporting. You can use SU24 to your advantage to deal with them by building your concept in SU24. By doing so, you do not have to remember each time what you wanted to achieve when maintaining individual roles. The same applies when someone else maintains the role later in the life cycle of the transaction when building other roles. SU24 based authorization concepts are robust and survive most SAP upgrades very easily.
What is the sense of authorizing forward navigation for ABAP list reporting and is it necessary? Having read SAP Note 113290, if you are following this blog series from the beginning, will have given you some good hints, but the next blogs will deal with SU24 maintenance as an expert SU24 artist.
Table of Contents
What is forward navigation from list reporting?
You cannot implement SAP for any module without reporting. Most of this is implemented as ABAP list reporting (ALV) which is navigable. More modern reporting such as SAP Business Warehouse and HANA application reporting effectively re-use the same technique. The user starts a reporting application which is visible to them. These applications have a selection screen and by hitting the “Execute” button the system presents a list. But the application does not stop there and nor does the authorization requirements. This is because if they (double) click on a line item, then they drill down into a deeper level and in most cases a different transaction code or reporting context, which requires different access control. That transaction code (eg. FB03 Display Finance Document) might also offer further navigation to other original documents (eg. Customer Orders), etc.
Reason 1: The role which contains the application for the list report should also contain the forward transaction navigation authorizations as far as you want it to go
This is a question of robustness of the roles and precise authorizations without having to add more roles (often based on speculation) to correctly equip the user with authorizations to do their work from reporting. That allows you to have where-used-lists in roles when maintaining SU24 should by now be clear. Also, you have fewer roles with more authorizations that are simpler to maintain.
You must consider that ABAP list reporting is by default display only, but the navigation might offer change options. Best practice is to maintain SU24 for the start application which the user can see in the menu or front-end application (e.g. Fiori tile). Also, add all the navigation options in SU24 to that start application transaction in the menu of the role. That results that the user of that role will never need another additional role to be able to use the reporting in display mode as far as what is intended in your concept.
The more “open book” your concept is within an organizational unit, the fewer roles you will have. Even change transactions can switch to display transactions in other modules when navigating using this SU24 based approach.
A good example can be any report within the “Information System” folder of the SAP Standard menu. Let’s take S_ALR_87013611 – Cost Centers: Actual/Plan/Variance as an example as it is widely in use.
The user can, via the list output, navigate to KS03 for the master record. Then to KS08 for the change documents and FB03L for the finance documents. Potentially also to the MM or SD original documents and Contracts Management via the global object services.
If the entry point is a list report which in display mode should always enable the user to access further navigation, then add that further navigation authorization to their entry point via SU24.
The user has less visible entry points in their menu. You have less maintenance for roles or assignments when they do navigate from the lists. Any future role (change) benefits from the same correct authorizations and robustness as well.
Reason 2: The forward navigation should include application authorizations and not the S_TCODE start authorization for direct navigation
This is a special case. As an example you want the user to start controlling (COPA) reports (controlled by RESPAREA field of various objects) and from there only access FI (controlled by various BUKRS objects) which prior were restricted by the RESPAREA. So the user must access the FI transaction FB03L for example from the list restriction. But they must not be able to access FB03L directly and display all BUKRS they have authorization for. The same applies to RESPAREA access based on dedicated selections without being able to see all RESAPEA data. This depends on the level of “open book” for the concept and “entry point” to implement granularity.
This challenge but also an opportunity for control is directly related to the concept of the ABAP statement CALL TRANSACTION and as of release 7.40 the ABAP language extension WITH AUTHORITY-CHECK. See the documentation on transaction SE97 for more detailed info.
Using SU24, you can maintain the application authorizations for the BUKRS to document that the user of this CO reporting must be able to navigate to FI documents (if that is intended) but only under this application context where the start authorization is skipped for the target transaction.
This approach via SU24 helps you to classify direct and indirect “friends” at a transaction code level. Also, it prevents excessive FI display access from sub ledgers (if you have that control requirement) and ensures that single roles can fulfill your control requirements without having to use “composite roles” or “enabler roles” concepts.
Conclusion
Using the tips from these first four blogs, you will typically still be at 99% field completion of your roles. With this blog, you will have a better understanding of how to make the initial investment in maintaining SU24 correctly for intended navigation.
As the level of maturity of SU24 proposals increases, you increasingly have the confidence in administrating the roles only via their menus and the organizational field values maintenance.
This way you define a concept for the roles and maintain metadata for them. The actual generation and the field maintenance of hundreds of objects in hundreds of roles via PFCG are now automated via the menu for robust single roles. You do not need thousands of roles anymore. Ideally, you have less than 100 master single roles already.
Previously in this series:
