cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
biterbit
Kudo Collector
Kudo Collector

Getting current SharePoint permissions on a file/folder

I have developed a solution for storing sensitive client documents in a set of folders in a SharePoint site's Shared Documents library: one folder per client. Individual access is granted to a folder when a user takes on a role in relation to the client, and removed when the user leaves that role. When the client moves to a 'closed' state, I reset all permissions to the default (no individual user access). I also use the individual permissions on a folder to determine who should be notified when a document is placed in the folder.

To do all this I use several Flows containing different HTTP calls to SharePoint:

1) When a user is granted access to a folder I use the action Grant access to an item or a folder

2) When a user's access is revoked I use the action Send an HTTP request to SharePoint with the URI set to:

_api/lists/getByTitle('Documents')/items(⁠<FolderID>⁠)/roleassignments/removeroleassignment(principalid=⁠<UserIDtoRemove>⁠)

3) When the client record is closed I use the action Send an HTTP request to SharePoint with the URI set to: 

_api/Web/lists/getByTitle('Documents')/items(<FolderID>)/ResetRoleInheritance()

4) When I want to notify users when a file is added to a folder I user the action Send an HTTP request to SharePoint with the URI set to:  

_api/web/lists/getbytitle('Documents')/items(<FolderID>)?$expand=RoleAssignments/Member/Users,RoleAssignments/RoleDefinitionBindings

and then I parse the output to get any PrincipalId values in the ['d']?['SharedWithUserID'] section of the returned body and then find the users' emails from that.

Checking the folders in SharePoint, it all seemed to be working fine and I could see the users' permissions being added and removed successfully as planned. Then I noticed that notifications were being sent to people who no longer had access to certain folders. These seem to be those whose permissions had been reset after the client record was closed. I confirmed that these users' IDs were being returned in the SharedWithUserID list, which I expected to be null. It seems that the ResetRoleInheritance action is removing users' permissions, as seen in SharePoint, but they are still included in the SharedWithUserID list.

Am I missing something here in relation to how SharePoint permissions work?

1 REPLY 1
biterbit
Kudo Collector
Kudo Collector

An update after more testing...

 

The situation is worse then I thought: when access is revoked (in step 2) this also results in the user being removed as seen in SharePoint, but still being returned in the SharedWithUserID list.

Helpful resources

Announcements
 WHAT’S NEXT AT MICROSOFT IGNITE 2022

WHAT’S NEXT AT MICROSOFT IGNITE 2022

Explore the latest innovations, learn from product experts and partners, level up your skillset, and create connections from around the world.

Register for a Free Workshop.png

Register for a Free Workshop

Learn to digitize and optimize business processes and connect all your applications to share data in real time.

Users online (2,514)