We are hiring and constantly growing! Have a look through our vacancies to find the right role for you!
GET PERMISSIONS, Short Form
1. GET PERMISSIONS $[PRIVILEGED$] $[ only_clause$]
ENTITY bdef $[FROM keys$] REQUEST request RESULT result_tab $[response_param$].
GET PERMISSIONS, Long Form
2. GET PERMISSIONS $[PRIVILEGED$] $[ only_clause$] OF bdef
ENTITY bdef1 $[FROM keys$] REQUEST request RESULT result_tab
$[ENTITY bdef2 $[FROM keys$] REQUEST request RESULT result_tab$]
GET PERMISSIONS, Dynamic Form
3. GET PERMISSIONS $[PRIVILEGED$] $[ only_clause$] OPERATIONS perm_tab $[response_param$].
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:
For all characteristics, the permission retrieval must be self-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.
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:
The following variants of the GET PERMISSIONS statement can be used: