Skip to Content

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.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Nick Yang

    Hi Vincent,

     

    Thanks for sharing this great how-to with the community. I went through similar requirement before and did a research on this. Below are my research result for your reference.

    There is an SAP-delivered add-on called “Field Masking for SAPUI5 and SAP Fiori”. Not sure you aware this or not. The purpose of this add-on is “for SAPUI5 and SAP Fiori is a solution that masks the screen output of restricted and sensitive data values at field level on SAPUI5 and SAP Fiori screens for unauthorized users.

    It consists of the following functions:

    • Field masking: This function allows only users with property-level authorization to view property values on SAPUI5 and SAP Fiori screens.
    • Field access trace: This function creates an access trace entry when the user accesses the fields configured for masking.

    Detail explanation can be seen from below SAP on-line help link.

    https://help.sap.com/viewer/1bf8a27721a248009a987a0159850d00/1.0/en-US/8caf18790e6d4595a1de19b944a70e31.html

    I also found Serban Petrescu his work on GitHub regarding this topic. His work is called “UI5-Auth” https://github.com/serban-petrescu/ui5-auth.

     

    Regards,

    Nick

     

    (0) 

Leave a Reply