Register Login

SAP Query: Authorizations

Updated May 18, 2018

A user can work with the queries of a user group, although he/she is not entered in this user group.

The user has the corresponding authorizations. An overview on how the authorizations can be set for an ABAP/4 query is described below.

The authorizations for an ABAP/4 query are controlled in two ways:


The authorization object S_QUERY with the values 'Change'(02) and 'Maintain environment' (23) and 'Translate' (67)

The user groups

The following constellations are conceivable:

1. A user has no authorization for the object S_QUERY and is not entered in a user group: This user cannot work with ABAP/4 query.
2. A user has no authorization for the object S_QUERY and is entered in user groups: This user may execute queries in the user groups in question (but not, however, change them).
3. A user has an authorization for the object S_QUERY with the value 'Change' and is entered in user groups: This user may change queries in the user groups in question.
4. A user has an authorization for the object S_QUERY with the value 'Maintain environment': This user may maintain functional areas and user groups (Transactions SQ02 and SQ03).
5. A user has an authorization for the object S_QUERY with the values 'Change' and 'Maintain environment': This user is treated as a 'superuser', as he/she can maintain all query objects. In particular, he/she can enter him/herself into all user groups. For this reason, a 'superuser' is always dealt with as though he/she were entered in all user groups, even if this entry was not made explicit.
6. A user has an authorization for the object S_QUERY with the value 'translate.' this user may undertake a language comparison with the query component for language comparison for all query objects.
As of  3.0C, authorization to maintain functional areas is further limited. A user who may maintain functional areas (authorization for the object S_QUERY with the value 'Maintain environment') may only place coding in a functional area (additional fields and coding at various times), if he/she has an authorization to edit programs. If he/she does not possess this authorization, during functional area maintainence the use can only choose fields and incorporate supplementary tables.


As of 3.1H the authorization query for editing programs is modified in such a way that the user only has to be able to edit programs that start with AQ.


As of  3.1I the authorization for maintaining functional areas is further enhanced. A user who is allowed to maintain functional areas (authorization for object S-QUERY with value 'Maintain environment') may only link additional tables or functional areas through direct reading or by defining a table join if he/she has an authorization for the tables in question (authorization for object S_TABU_DIS).

This behaviour was changed as of  4.5A:
A user who is allowed to maintain functional areas (authorization for object S_QUERY with the value 'Maintain environment') may add any number of additional tables or define functional areas either with direct reading or via a table join for all R/3 tables.
When a query is carried out for the corresponding functional area, it is checked whether the executing user is authorized to read the corresponding tables (authorization for object S_TABU_DIS).

Note: If further authorization checks are required (e.g. for certain controlling areas, company codes, etc.), the developer of the functional area/InfoSet must store them in the functional area. Depending on the kind of check and the release, the coding for the authorization checks can be implemented at INITIALIZATION, START-OF-SELECTION, AT SELECTION-SCREEN or at record processing. If it depends on the field contents of a record whether this record is allowed to be displayed to a user, the check needs to be carried out at record processing in general; with other checks, different times are possible.

Customers have often requested that the query tool should automatically carry out authorization checks from other applications for controlling areas, company codes, etc. In general, this is impossible since authorization checks are not assigned directly to table objects. The authorization checks are rather a part of the application program logic. It is true that some applications check for the same authorization objects to make customizing easier, but in general, a generic transfer of authorization checks from applications is impossible. For queries, we decided to transfer exactly the authorization check for S_TABU_DIS carried out in table maintenance (/nse16 or /nsm30) is transferred (see above).

For a functional area that was created via a logical database, the authorization checks for the tables need to be carried out in the database program.

(Refer also to 89744).

Within a user group, only those explicitly allocated to a user group by the administrator may work with functional areas. In functional areas the determination is made concerning which information may be read. A functional area usually refers to a logical databank. However, one or more tables can be addressed. It is within the functional area, too, that the determination is made concerning which fields of the table under consideration may be read.
The combination of authorizations given for the authorization object S_QUERY and for the maintainance of user groups (entry of end user and allocation of functional areas) allows one to determine quite exacly which information may be read by which users.
Details are available in chapter 1 of the User Guide for ABAP/4 Query.

Read Here at SAP ABAP Forum to Get Answers for More Questions like aforementioned.


×