Determine a users permission or permission level f...

TomRBerg · ‎02-10-2023

Hi guys,

this one has me stumped, primarily as I'm not a developer and no expert on JSON and SharePoint REST API stuff.

Case

There is an Archive site (communication site) with a document library named "Arkiv" (norwegian, means "Archive) and everyone read.
For certain folders throughout the folder hierarchy (primarily at folder level 2, sometimes 3) certain users/groups are granted the custom permission level "Contribute - no delete or edit") that allows users to create items (folders/files), but not change existing items.
Sometimes the user has a need to update an existing item with a new version of the file, but to avoid the user accidentally moving a file from another site thus erasing that files version history, the desire is to provide a flow with elevated permissions so the user can accomplish this.
- I created a test flow of type "For selected file" with the trigger asking for a file, and for the content of the file the user uploads I use the "Create file" action giving it the selected file as filename. I have tested and this works - the uploaded file becomes the most recent file in the files version history. All was well...

However, here comes the crux. I was then asked to ensure that the flow runner can only run this update flow if they were able to create files in the folder in the first place, to avoid the flow runner from updating files in folders they were not supposed to do so in. And this is where I am a bit stumped. As I understand it, I cannot have RunAs flows run with actions from the same connector but under different contexts (i.e. one action run as whoever RunAs triggered the flow and another action from same connector later run as elevated user).

Suggestion 1 - not tried (solution flow with child flows)

One suggestion, which I assume could work, would be to create a solution so I can have childflows and

have the "For selected file" flow run in the users context and attempt to create the uploaded file in the folder as a temp file
if that fails, the user did not have create permission, so on error the user is informed that they cannot do that there
if it succeeds, the user has create permission, so we then call a child flow that runs under elevated privilegies that takes the temp file, puts it into the version history of the file to be updated (I'm guessing Get file content + Create file actions) and deletes the temp file...

The primary reason that I have not gone for this approach is uncertainty about the licence requirements for solutions and not being quite aware of them until I was already deep into the approach I began with. My second concern with this approach is of course that the recycle bin of that site will contain a lot of deleted temp files that won't be deleted until 93 days have passed. It feels... crude? 😅

Scenario 2 - REST API to determine effective permission - the approach I am on currently

From a little googling, it looked like it could be possible to accomplish something similar to the "Check permission" button using REST API calls. Ideally, I want my flow running under elevated permissions to determine if the (RunAs) flow initiator has either the "Add item" permission or the custom permission level in a folder and then proceed from there.

My problems here is figuring out the correct REST API call to use and how to handle the JSON that it returns to get the values I need to check again. I get a ton of information back but I am not a JSON guru and my Parse JSON attempts validate but still gives me issues trying to parse them...

I want the flow to test against a given folder if a certain user either has "Add item" or has access due to a custom permission level "Contribute - no edit or delete"

I created a flow purely to determine permissions and I have been playing around a lot in it, so it is a bit untidy with regards to use of dynamic data and so on, but any input, blog links and so on is appreciated 😅

Screenshots of flow (also as OneDrive link😞

StretchFredrik · ‎02-10-2023

Have you found this post?

Solved: Check if a user has access in sharepoint document ... - Power Platform Community (microsoft....

TomRBerg · ‎02-10-2023

I should add that HTTP request 3 returns two values - a "High" and "Low" appearantly for the correct user. However I have been struggling to interpret those values...

TomRBerg · ‎02-10-2023

I have! It was the basis for version 3 - the problem is that it only tests on a library and not a folder inside the library I think?

TomRBerg · ‎02-10-2023

I'll give it another try with my hacks. Thanks for reminding me of it!

StretchFredrik · ‎02-10-2023

What is the reason for checking this? Is everyone able to read/edit the folders but not everyone is allowed to archive?

TomRBerg · ‎02-10-2023

Everyone has read access. Certain users have write access but not modify access. The purpose of the flow is to provide only these users a way to modify an item but also prevent them from accidentally overwriting the item using a move action from another library for example.