Sometimes we have been asked by the customer why the roles that are called display actually are not display roles? How would you proceed in that case?
There are a few things that needs to be checked in this scenario. Firstly, the role name is just text, and it can be the case that the name is not at all in line with the role contents.
After that, check two things first:
1. Transactions
a. You should only assign transactions that allow display functions to be performed to display roles. This means in practice that for example transactions like CJ20n Project Builder should never be assigned to a display role. This is a transaction that allows many activities, i.e. create, change, display, activate, lock etc. from one transaction. Even if it is given in display mode, if a user has other roles then this transaction may open up to allow something else than display. Therefore, this type of transactions should never be assigned to a display role.
b. Another group of transactions that are not to be assigned to display roles are transactions that have no authorization objects assigned to them. For example, in the basis area there are many transactions like this. If it is not certain that a transaction like this does not allow anything else than display, then it should not be assigned to a role.
2. Authorization objects
a. In SAP the detail level authorization checks are executed against the authorization object field level values. If these fields contain too much values, the accesses leak and users gain more than display access. This is true only if transactions are assigned that allow something else than display (see above). The field ACTVT is key in this, however there are other fields as well that steer this and hence the configuration of the object values is an important work step in setting up display roles correctly.
How do you know then what transactions to assign? Good tools are table TSTC, transaction SU24 and the application experts for specific areas. Transaction SU24 tells us together with table TSTC whether we canaccess a transaction in something else than display. Application experts often know this too, and hence the role design step is a crucial step and right persons need to be involved.
We have decades of experience working on these topics. We have classified transactions to help our role development work and we have gained knowledge around this topic that might be valuable for your situation too. With our help you can more easily setup your display roles reliably.
Christa Coulter