Mapping Authorization Check result to SAPUI5 field control

[Former Member]

Introduction

It 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

<EntityType Name="SalesOrder" >

    <Key>

        <PropertyRef Name="SalesOrderId"/>

    </Key>

    <Property Name="SalesOrderId" Type="Edm.String" sap:label="Sales Order" MaxLength="10"/>

    <Property Name="ServiceFeeAmount" Type="Edm.Decimal" sap:label="Service Fee Amount" sap:field-control="ServiceFeeControl"/>

    <Property Name="ServiceFeeCurrency" Type="Edm.String" sap:label="Currency" MaxLength="5" sap:field-control="ServiceFeeControl"/>

    <Property Name="ServiceFeeArticle" Type="Edm.String" sap:label="Description" MaxLength="40" sap:field-control="ServiceFeeControl"/>

    <Property Name="ServiceFeeControl" Type="Byte"/>

</EntityType>

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.