Mapping Authorization Check result to SAPUI5 field control
Introduction
Mapping Authorization Check result to SAPUI5 field contro: lIt is a generic technical requirement to have authority check result to change the UI5 control state. For example, UI5 should only display the field if the user has a display auth; UI5 field should only be in edit mode if the current user has a change authorization.
This article is aiming to solve the above problem by leveraging ABAP Authorization Object & dynamic field-control capabilities.
Business Requirements
There’s special item in the sales order. The business needs to hide this item to certain users; while enabling senior users to be able to review and change it. This is controlled by users authorization settings.
Firstly, we need to create a mapping between UI fields, their control field, and authority-check fields.
The user interface has 3 fields to show service fee information.
- ServiceFeeAmount (the amount of the service fee)
- ServiceFeeCurrency (its currency)
- serviceFeeArticle (its description)
These fields are controlled by a UI control field, namely
- ServiceFeeControl
That is controlled by Authorization Object, AUTHORDER, with field mapped to
- FIELD
For example, if user1’s user profile is ACTVT = ’02’, FIELD = ‘SERVICE_FEE’, he is then able to edit all the 3 fields in the UI. While user2 has ACTVT = ’01’, FIELD = ‘SERVICE_FEE’. User2 is only able to view those fields, but unable to make any changes to them.
Mappings
1. Mapping UI fields to authorization object fields
The table manages UI field to Semantic field to authorization field mapping. This is a “C” table.
Entity | UI Field | ControlField | SemanticField | Auth. Object | Auth. Field |
SalesOrder | ServiceFeeAmount | ServiceFeeControl | SERVICE_FEE | AUTHORDER | FIELD |
SalesOrder | ServiceFeeCurrency | ServiceFeeControl | SERVICE_FEE | AUTHORDER | FIELD |
SalesOrder | ServiceFeeArticle | ServiceFeeControl | SERVICE_FEE | AUTHORDER | FIELD |
According to this configuration, at design time, the Entity in OData service is redefined in the ZCL_XXX_MPC_EXT class. It maps the ordinary UI fields to the “field-control” field, which is ServiceFeeControl in our case.
2. Mapping auth. check result to field-control value
The value of Control field is defined as :
- 0 = hidden
- 1 = read-only
- 3 = optional
- 7 = mandatory
So we can easily map this to authority check result. This table is designed as s table.
ACTVT=’02’ | ACTVT=’03’ | Control field | |
Yes | – | 3 | Optional |
No | No | 0 | Hidden |
No | Yes | 7 | Readonly |
This control field result is determined at runtime in the ZCL_XXX_DPC_EXT class.
OData
1. OData metadata
After applying UI field mapping to authority object mapping, our entity looks like this
UI5 can use SmartField and bind the property to it. Because at runtime the correct value for the control field is returned in the GET response(our example the “ServiceFeeControl” field returns value 0, 3 or 7), UI5 is then able to interpret the field with the intended state.
Conclusion
UI5 field-control is designed to tackle runtime field states. Authority check result is one of the most common usages. Our example maps the UI5 field state to auth. object fields. And we implemented it in the Gateway MPC/DPC classes.
New NetWeaver Information at SAP.com
Very Helpfull