Post
Ask Question

Changing Permissions Using SharePoint 2013 Workflow With REST Call - Part Three

Introduction

 
This is the final part of the “Changing Permissions using SharePoint 2013 Workflow with REST Call” series. Before reading this article, I recommend you to go through the previous parts:
So, we were discussing using the REST API with the SharePoint 2013 workflow to change SharePoint list item permission. By default, SharePoint 2013 workflow doesn’t have any provided action to change permission, which we have enjoyed in SharePoint 2010 workflow. As Microsoft declared the SharePoint 2010 workflow’s retirement in SharePoint online, people are searching for an alternative approach. This is an alternative to change the permission of an SP list item.
 
In the previous parts of this series, we already discussed on activating the App Step, providing elevated privilege to App Step, breaking inheritance and removing permission of SP list item. In this article, we are going to discuss the step by step procedure to grant permission for an SP user or group on an SP list item.
 
Before granting permission on any item, we have to break the inheritance permission. However, it is not necessary to remove the permissions on that item. So, we have to complete the steps of Part 1 first, but Part 2 is not necessary. For assigning permission to any SP user or group, we need that user/group’s Principal ID and the role definition Id of the role which we want to assign. So we have to understand what Principal ID and Role Definition ID is and we will discuss these before starting the main topic.
 

Get Principal ID

 
Principal ID is an integer value that represents an SP user ID or a group ID. In other words, you can say that Principal ID is the SP ID of SP User or Group and this principal ID is always unique in each site collection but can be different in a different site collection. In SharePoint, every individual user gains access directly through a role assignment, or indirectly through membership of a SharePoint group that has a role assignment. In a direct role assignment, the user is considered as the principal, while in a SharePoint group role assignment, the SharePoint group is considered as the principal. That way their SP is called Principal ID.
 
We can get the principal id of the SP user or group who are stored in the 'Person and Group' type field of the list. Workflow can get the user/group’s principal id from that field.
 
But the requirement is that the field has to be a 'Person and Group' type field. If we don’t have the required user or group stored in the ‘Person or Group’ type field in the list, we can get the Principal id with the help of REST API.
 
For SharePoint users, we will need the user email for the REST call. The REST API URL for getting SP user Principal ID is as shown in the following:
  1. <Site Address>/_api/web/SiteUsers/getByEmail('<User Email Address>')/Id  
For SharePoint Group, we need the group’s display name as a parameter. The REST API URL to get the SP group’s Principal ID is given below:
  1. <Site Address>/_api/web/sitegroups/getbyname('<Group’s Name>')/Id  

Get Role Definition ID

 
We already know we will need the role definition id for assigning permission using REST API. So first, we need to understand, what is Role Definition ID. In SharePoint, We use different types of permission levels as Full Control, Edit, and Contribute to manage Site/List/item level accessibility. And sometimes we create custom permission for business requirements. These permissions are defined in the SharePoint with a unique id which is called “SharePoint Role Definition ID”.
 
The details about role definition id and steps to get them are described in this article: Get SharePoint Role Definition ID.
 

Assign Permissions

 
Now we have both of the pre-requisites for assigning permission to any SP user or group. We have to take another Stage in our SharePoint 2013 Workflow. Now let’s start,
  • Add an App Step inside this stage for assigning permission. All the actions need to be written inside the App Step.
  • We need a dictionary variable to use as a Request Header for the rest call. As we already have a dictionary variable ‘JSONRequestHeader’ with all the properties set (in part 1), we don’t need to create one new.
  • Now create an integer type variable ‘principalID’.
  • Then store the Created By user’s principal id in ‘principalId’ variable.

Fig 1: Getting Principal ID of Item Creator
  • To do that, click on the function icon and you will see the popup window as shown in the above image (Fig 1).
  • Now Select ‘Current Item’ in position 1.
  • Select ‘Created By’ in position 2.
  • And select the ‘User Id (as Integer)’ in position 3.
  • The value will be stored in the variable ‘principalID’.
  • Create a string type variable called ‘reqURL’.

Fig 2: REST URL for granting permission
  • Then store the REST API URL for assigning permission to the user or group in the ‘reqURL’, as shown in the above image (Fig 2).
  • Here is the REST API URL is given below,
    1. [%Workflow Context:Current Site URL%]/_api/web/lists/getbytitle('[%Worklfow Context:List Name%]')/items([%CurrentItem:ID%])/roleassignments/addroleassignment(principalid='<Principal ID>',roleDefId=<Role Definition ID>)  
  • Here, we have provided the role definition id 1073741826 for the ‘Read’ permission.
  • Now, add the action ‘Call HTTP web service’ inside the App Step.
  • Click in the ‘this’ link with the blue color of this action statement and a window will pop up like the below image (fig 3).

Fig 3: Call HTTP Web Service Action
  • Set the ‘reqURL’ variable, in which the REST URL has been stored, in position 1 as shown in the above image.
  • Set the HTTP method as ‘HTTP POST’ in position 2.
  • Click the ‘OK’ button.

Fig 4: Call HTTP web service property for Assigning Permission
  • Now select the action statement and click on the option ‘Properties’ which will open the Properties pan (Get it by right click) as shown in the above image (Fig 4).
  • Here, set variable ‘JSONRequestHeader‘ as RequestHeaders property which we have already created (In Part 1) as shown in the image above and click OK button.
  • The part for assigning the Permission of a list item is completed. The workflow looks like shown below:

Fig 5: Stage of the SP 2013 WF for assigning permission
  • Publish this workflow and create an item in a list item.
  • Now run the workflow for the newly created item.

Fig 6: The Permission Details page before running the workflow
  • We can see from the above image (Fig 6), before the permission pan was showing the Inheritance Panel where we have the option to stop inheriting the permissions.
  • And showing different groups with their permission details.
  • Now let’s run the workflow for that item and check the permission details after completing the workflow successfully.

Fig 7: Permission Details after running the workflow
  • Here we can see that after running the workflow, we have the control to delete unique permissions and grant permission for this particular item as shown in the above image (Fig 7).
  • It happens due to running the Breaking Inheritance stage of the workflow (described in part 1).
  • And we can also see that the groups which had permission on this item previously, are not showing. The groups permission has been revoked by running the remove all permission stage of this workflow (described in part 2).
  • The user “Md. Tahmidul Abedin” got read permission on this item, as we granted in the set permission stage. Similar to this, we can assign permission to a SharePoint group by using that group’s principal id.

Conclusion

 
As we already saw, in this approach we have to call an HTTP request for granting permission for each SP user and group. For providing access to multiple user or group, have to call the HTTP request multiple times. But instead of writing the statement again and again, we can execute the statement inside a loop and can provide the different Principal ID and Role Definition ID by looping.
 
Other than this approach, we can also use Power Automation (MS Flow) to change permission where we have the provided actions to remove all permission or grant permission to an SP user or domain group. To know details on that topic, you can read this article: Set SharePoint List Item Permissions Using MS Flow. But one thing to consider that we can’t grant permission for the SharePoint group with provided actions of MS flow. We need to use the REST API endpoints again to perform that. Similarly, only breaking inheritance permission or removing a specific user/group’s permission from an item is not achievable with the provided actions until now, since MS flow is providing. In that situation, we have to use rest API endpoints to manage the item level permission in MS flow.
 
I hope this article will help you. Be safe, and happy coding! 


Similar Articles