Start of Content Area

This graphic is explained in the accompanying text Special Features of the Authorization Check in Dialog (Master Data) Locate the document in its SAP Library structure

Problem Description I

In the dialog transactions for master data, authorization checks always run from "top to bottom" first. This means that even if the check is for read access, the system checks whether write authorization exists for the corresponding data record. The authorization level is checked in the following order:

  1. W (Write) = write access
  2. S (Symmetric) = write access using the Symmetric Double Verification Principle
  3. E (Enqueue) = write access using the Asymmetrical Double Verification Principle. E also enables you to create and change locked records
  4. D (Dequeue) = write access using the Asymmetrical Double Verification Principle. D also enables you to change the lock indicator.
  5. R (Read) = read access

As soon as the authorization check has run successfully, the result is stored in the buffer and the check is ended.

Consequently, all write authorizations in the dialog also work as read authorizations. However, since there are special modules that check for read access directly, this can lead to an inconsistent system response.

Solution I

Ensure that you always specify a read authorization together with the write authorization.

Problem Description II

The order in which the authorization level is checked can have the following additional effect: a user with authorization levels E and D for a data record, actually needs authorization level E to access the data record in question. Due to the business importance of authorizations, you would, however, expect this user to have the same authorizations as a user with authorization level W. This is also the case for users with the combinations E with S and in particular D with S.

Solution II

In future releases, it is planned to carry out this interpretation in a business-oriented sequence rather than the present technically oriented sequence. For this reason, you should not implement any authorization concepts that are based on the authorization level combination E, D or S for an infotype for a user.

Problem Description III

The system always checks infotypes with subtypes using the corresponding specification of the subtype field when it accesses the initial screen for single record maintenance. If you attempt to edit an infotype record without specifying a subtype, the authorization check is performed using the <BLANK> subtype. This often results in users with limited subtype authorizations seemingly not being able to access data records.

Solution III

There are two ways to avoid this:

  1. Users always explicitly specify a subtype for which they have authorization.
  2. Users are granted an additional authorization for the dummy subtype <BLANK>.

Note

The second option is preferable. In principle, users are not granted any unnecessary authorizations since the <BLANK> subtype does not exist and is always explicitly checked when users access existing data records and when they create new data records.

 

 

End of Content Area