023: Recycling-Heroes - Feature Control and Authorization (Contact)

Table of contents

• Introduction
• Authorization Object
• Helper Class
• Behavior
• Permissions
• Features
• CDS
• IAM App
• Summary

Introduction

In this episode, we'll look at our application's permissions. So far, we've been able to run the application and see all the data records, and all actions with the data work fine. Therefore, we'll first restrict the various actions and then, finally, the data itself.

 

Authorization Object

First, we need a new Authorization object for our data. Using the context menu in the "Project Explorer," we can search for "Authorization" and find two entries. Since we want to differentiate the data by type in addition to the actual activity, we first need to create a new "Authorization Field". We assign our data element to this field and give it a short name. Unfortunately, we still only have 10 characters available. After creating the element, we can use the "Search Help" button to check whether our values are being retrieved correctly, as we want to see them later in the search help. Saving the object is sufficient here.

Next, we create the actual authorization object in the system and give it a name. Here, too, we only have 10 characters available. We can now assign our own authorization field to the object. After creating the new object, the activity field is already included. We will need this later to control the various actions and the display of the data individually. Several activities are already suggested to us in the lower section, which we also need.

With this, we have everything we need to carry out the authorization check and restriction and can now turn to the actual implementation.

 

Helper Class

Let's extend our helper class to include the functions of the authorization check. To do this, we switch to the helper class that we had already created. First, we need a base type for the activity in order to subsequently create constants. This way, we don't have to hard-code the various possibilities in the code and have descriptive values for the different names.

Once we've finished that, we create a new method that checks the permissions for an activity and a contact type and returns a Boolean value. Within this method, we then implement the permission check against our authorization object. We compare the activity and type against the passed values and return the result using the XSDBOOL function.

In addition to the actual check, we create further helper methods to keep the coding manageable and simple later on. For this, we need additional return types for new methods. The first type should return the respective permissions for creating a contact for all contact types. The second type is planned for the different activities for a type. Therefore, we need all created activities here.

Now let's implement the two methods in the helper class. The methods return the respective types, and for the various actions, we also need the contact type. For the different Create operations, we can hardcode all values, since we only need the result of the authorization check. The second method is quite similar, but here we consider the different activities and use the passed-in type. This gives us the result from the two methods, indicating which authorizations are available to us. After executing the ABAP Cleaner, we can activate the class and we're done.

 

Behavior

Now we need to prepare our actions in the behavior definition for the checks. For the Create action and the various factory methods, we have already activated global permission checks, so a method is available to us in the behavior implementation. Now we activate the Feature Control to Update, Delete, and Edit. Since, for example, no type is yet defined during Create, this option is defined globally. Whether a record can be modified or deleted depends on the data of the individual record, so it is an instance-based action. Once we have saved and activated the object, we still need to implement a new method.

 

Permissions

For better clarity, we move the method to the other check methods and then take care of its implementation. Let's start with the authorizations and look at the "GET_GLOBAL_AUHTORIZATIONS" method. The "Requested" structure is used to query which field is currently being checked. We should fill the "RESULT" structure with the corresponding status. The return structure contains an entry for each of the various defined fields and actions. This structure is dynamically generated from the behavior definition settings. To do this, we again create an instance of the helper class and use our new method to retrieve the authorizations for the creation process. We then check each action individually, and if no authorizations are present, we restrict them. A constant structure is available for this purpose in the standard class. Afterwards, we can copy the line and adapt it to the three scenarios.

Now let's test the UI and its behavior. To do this, we open the application and refresh it. If we now try to execute a Create action, we receive the standard message that we do not have permission to execute it. The second action is no better, so the permission restriction is working for us.

 

Features

In the next step, we want to implement the Feature Control. This will deactivate the entire feature in the UI when the corresponding condition is met. The keys of the entities are available to us in the method, since we are working within the scope of individual instances. Basically, we have a similar structure to the permissions for selection. In the first step, let's copy our helper class again and use the instance to read the entries for the keys.

Next, we process the various data records as usual in a loop. Since we are adjusting the control flags, we first create an entry in the result table and bind the record to a reference to adjust the contents in the following steps. To do this, we call our new helper method to get the settings for the current type. If there are no permissions for the action, we disable the action via the control flag. In the first step, UPDATE and EDIT are the same. The EDIT comes from the draft because we want to block the actual action in the UI. We repeat the same process for DELETE, but here we only need one action.

Looking at the actions in the UI, we see that both actions are unavailable within the data record. In the List Report, we can also select records, and the "Delete" action is unavailable. This indicates that different permissions apply to different actions.

 

CDS

Since we have now restricted the actions, in the final step we will address the Core Data Services and restrict the displayed data. To do this, we define a new Access Control on the CDS View. Here, we can first assign the same name as for the Core Data Service. We'll use "PFCG" as the template, since we want to implement a classic authorization. Then we define the fields we need from the views for authorization checks. Here, we need the contact type. Within the parentheses, we define the authorization object and the authorization fields in the order they match the fields of the CDS view. Finally, we define the fields to which we assign fixed values, such as the activity with 03 for display.

After activation, we can view the data preview via the context menu, but we won't see any data there because we don't have the assigned authorization. The restriction has thus been successfully implemented. If, however, we call the preview at the consumption level, we get all the data again, since we have no check at this level and the access control is not automatically inherited.

Therefore, we also create a permission check for the consumption view. The name remains the same as the view. We don't use the PFCG template, but rather the template where we inherit the permissions from the interface layer. This means we only have to implement the attribute once and can reuse it at higher levels. You should now no longer see any data records in the data preview.

 

IAM App

Let's go back to the UI and load the data records; no information is displayed here either. If we try to create a new record, we will receive the corresponding error message from the system.

The easiest way to grant ourselves the necessary permissions is via the IAM app. There, we can define which permissions we automatically receive when we have this tile or application. In the IAM app, we switch to the "Authorizations" tab and can directly assign permission objects. Therefore, we search for our object and add it. We grant permission for all actions except "Delete" and assign ourselves the employee permission. After saving, we can propagate the new permissions to the Launchpad via "Publish Locally," which may take a while.

Finally, we go to the Launchpad for testing and try to load the data again. We now see all employees, but no other data records. If we try to create a new address, we still receive an error message. If we now navigate to a record, we see that the Edit button is active, but we do not have permission to delete the record. Finally, we try to create a new employee, which brings us to the corresponding dialog.

 

Summary

In this episode, we looked at the topic of permissions, created a new permission object, and restricted the permissions step by step. Finally, we checked whether we could work with the application again with the appropriate permissions.

That's it, thanks for watching and see you next time. 

 

YouTube
Video