Get Example source ABAP code based on a different SAP table
ID GET-PERMISSIONS • GET PERMISSIONS ABAP_STATEMENT_EML
GET PERMISSIONS>
ABAP_SYNTAX_FORMS
GET PERMISSIONS>, Short Form> 1 GET PERMISSIONS $[PRIVILEGED>>$] $[only_clause>$] ENTITY entity $[FROM keys$] REQUEST request RESULT result_tab> $[response_param>>$].>
GET PERMISSIONS>, Long Form> 2 GET PERMISSIONS $[PRIVILEGED>>$] $[only_clause>$] OF bdef ENTITY entity1 $[FROM keys$] REQUEST request RESULT result_tab> $[ENTITY entity2 $[FROM keys$] REQUEST request RESULT result_tab>$] $[...$] $[response_param>>$].>
GET PERMISSIONS >, Dynamic Form> 3 GET PERMISSIONS $[PRIVILEGED>>$] $[ only_clause>$] OPERATIONS perm_tab $[response_param>> $].>
What does it do? Retrieves information about permissions of RAP BOs. Permissions are defined on operation and field level, for example, operations can be disabled and fields can be set to read-only. Permissions are checked when EML requests are processed by the RAP runtime but they can also be requested upfront by RAP BO consumer> via a GET PERMISSIONS> statement. The permissions cover multiple aspects:
Global authorization and instance authorization>
Global authorization: Checks whether the current user is allowed to execute an operation in general, i. e. independent of the data to be processed, for example, a user must not change data.
Instance authorization: Authorization checks that can be defined based on a concrete value of an instance's field.
Global feature control and instance feature control>
Global feature control>: Feature controls that depend on external factors like specific user settings or the business scope.
Instance feature control>: Checks depending on the state of an entity instance.
Static feature control>: Specifies individual fields of an entity that have certain access restrictions, for example, fields that are marked as readonly> in the BDEF>. For all characteristics, the permission retrieval must be user-implemented in RAP BO provider implementations except for static feature controls. In latter case, the access restriction is directly defined in the BDEF. One example is when a field is marked as readonly>. Depending on the context, GET PERMISSIONS> statements in RAP BO consumers> and RAP BO provider> trigger the calling of the RAP handler methods> FOR $[INSTANCE$] AUTHORIZATION>>, FOR $[INSTANCE$] FEATURES>>, FOR GLOBAL AUTHORIZATION>>, or FOR GLOBAL FEATURES>>. The handling and consolidation of the permission result as well as general best practices are outlined in the topic GET PERMISSIONS>, Guidelines>. One example is when the permission result contains merged information. Among others, static feature controls are merged with global feature controls. Permissions can be retrieved for the following:
Create, update and delete operations
Associations with create-by-association operations>
Fields
Actions ABAP_NOTE Permissions cannot be retrieved for internal> elements like internal associations and internal actions. For virtual elements> in projections, there are only static features available.