Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing External Data →  Data Consistency →  Authorizations 

AUTHORITY-CHECK

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


AUTHORITY-CHECK OBJECT auth_obj [FOR USER user] 
 
                      ID id1 {FIELD val1}|DUMMY 

                       [ID id2 {FIELD val2}|DUMMY] 

                        ... 

                       [ID id10 {FIELD val10}|DUMMY].

Addition

... FOR USER user

Effect

This statement checks whether an authorization is entered in the user master record of the current user or of the user specified in user for the authorization object entered in the field auth_obj, and whether this authorization is sufficient for the request specified in the statement. auth_obj expects a flat character-like field containing the name of an authorization object. If the addition FOR USER is not specified, the authorization of the current user is checked.

If id1 ... id10 is specified, you must have at least one and a maximum of 10 different authorization fields listed for the authorization object specified. id1 ... id10 expects flat character-like fields containing the names of the authorization fields in uppercase. If an authorization field is specified that does not appear in the authorization object, checks are not possible and sy-subrc is set to 4. Each specified authorization field expects either a value to be checked by FIELD in a flat character-like field val1 ... val10 or the addition DUMMY. The value being checked can have a maximum of 40 characters and a maximum of 40 characters from val1 ... val10 are evaluated. Fields that are longer produce a warning from the extended program check.

The authorization check is carried out if the check indicator for the specified authorization object for the current context is set to check with any proposal status. If the check indicator is set to no check, no authorization check is carried out and sy-subrc is set to 0, as with a successful check.

The authorization check is successful if one or more authorizations are created for the authorization object in the user master record and if, for at least one of the authorizations, each of the value sets defined there for the authorization fields specified using ID includes the value val1 ... val10 to be checked. Authorization fields that are not included in the statement or that have DUMMY specified for them are not checked. If the check is successful, sy-subrc is set to 0. Otherwise, it is set to a value not equal to 0 (see below).

System Fields

sy-subrc Meaning
0 Authorization successful or no check was carried out. An authorization for the authorization object was found in the user master record. Its value sets include the specified values.
4 Authorization check not successful. One or more authorizations were found for the authorizationobject in the user master record and they include the value sets, but not the values specified, or incorrect authorization fields or too many fields were specified.
12 No authorization was found for the authorization object in the user master record.
24 This return code is no longer set.
40 An invalid user ID was specified in user.


Notes

  • The authorization fields of an authorization object are fields for data and a field with the name ACTVT for activities. Activities are represented by IDs with two characters defined in the ACTVT column of the database table TACT or have a customer-specific definition in TACTZ. Possible activities are assigned to the authorization field ACTVT in the authorization object. In the user master record, you have authorizations for data and activities in the form of operands for logical expressions stored as value sets.
  • When checking the authorization of the current user without the addition FOR USER, the content of the system field sy-uname is not evaluated, but the actual user name is used instead., ,
  • The most important contexts for which check indicators can be set are transactions. The execution of a statement AUTHORITY-CHECK can have different results depending on how the current program flow was started. In general, a check indicator should always been set to check.
  • For authorization objects of the areas AS ABAP (BC) and human resources management (HR), a check indicator cannot be set to no check.
  • Do not specify an authorization field of the specified auhtorization object more than once. If an authorization field is specified more than once, however, the check takes place as if it were dealing with different fields, that is, the specified values are checked individually.
  • The transaction SU53 shows the results of the last authorization check for a user.

Addition

... FOR USER user

Effect

If the addition FOR USER is specified, the authorization of the user is checked whose user name is specified in user. user expects a field of the same type as the system field sy-uname. If the user name is invalid, sy-subrc is set to 40.


Note

This addition replaces the function module AUTHORITY_CHECK.


Example

Checks whether the current user has the authorization to display the airline he or she entered on the selection screen. The authorization object used here is S_CARRID and includes the authorization fields CARRID for identifying an airline and ACTVT for the activity. The code "03" represents the activity "Display", which is one of the activities assigned to the authorization object S_CARRID.

PARAMETERS carr TYPE spfli-carrid. 

AT SELECTION-SCREEN. 
  AUTHORITY-CHECK OBJECT 'S_CARRID' 
    ID 'CARRID' FIELD carr 
    ID 'ACTVT'  FIELD '03'. 

  IF sy-subrc <> 0. 
    MESSAGE 'No authorization' TYPE 'E'. 
  ENDIF.