Override SharePoint List Item Permissions

[jarodpearcy]

Hello,

I have successfully created a Flow that breaks permissions and sets the user's permission to read only for certain items in a list using HTTP API call.

The problem is that now no one has any access to the items except for the user's read only permissions.  I am a global admin and the owner of the list with Full Control of the list and the subsite both explictly and by group membership.

I've rerun the HTTP API based Flow again breaking permissions and setting the new permissions for both the test user and myself but no further modification to the items is happening.

Is there any way to reset the permissions?

[RezaDorrani]

Hi @jarodpearcy 

Try using the new MS Flow actions for setting permissions

https://flow.microsoft.com/en-us/blog/july-updates-for-microsoft-flow/

Regards,

Reza Dorrani

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly

[Pstork1]

The simplest way would be to run the HTTP call and re-establish inheritance of permissions for the item.  That would reset everything back to normal.  Otherwise, there are ways to give multiple users or groups permissions using the same REST calls you've already used.

[ScottShearer]

@jarodpearcy 

Have you tried making yourself an SCA in the site collection (not a site owner)?  You can do so in the SharePoint Office 365 admin console.  As an SCA you should be able to see everything regardless of the permissions as well as reset permissions.

[jarodpearcy]

Hello Reza,

I tried your suggestion of using the SharePoint 'Grant access to an item or a folder' connector and the flow completed successfully with a Status Code of 200.  However, nothing changed.  The Recipient still has Edit permissions when set to View Only.

Any idea why everything appears to work yet nothing changes?  Does inheritance need to be broken using the SharePoint connector?

[RezaDorrani]

Hi @jarodpearcy 

That should grant access

There is also a stop sharing an item or a folder, whic revokes all access to an item to all people except for Owners

Try that first and then try grant access (assuming Flow is being run by the site Owner)

[jarodpearcy]

Hello Scott,

I discovered that I was targeting an Office 365 Group's SharePoint site and not a team site.  I've recreated the tables on a new team subsite and am trying to recreate the problem.  

However now the API call is returning a status of insufficient permissions even though it appears to have a valid access token.

Is it possible for the https://accounts.accesscontrol.windows.net/....Tenant ID..../tokens/OAuth/2 request to return a token but it not have access permissions?

[jarodpearcy]

Okay, so you're saying if a user already has Edit permissions then setting it to Read permissions does nothing to limit permissions.  I would have to revoke all permissions and then grant Read permissions.  Is that right?

[Pstork1]

That is correct.  Permissions in SharePoint are always additive.  Its the sum of whatever permissions you get for that particular securable object of whatever securable object it inherits permissions from.

[jarodpearcy]

This approach works if the Owner is excuting the flow.  However the flow is part of a PowerApp that is being executed by the user and does not have the access to reset permissions via the SharePoint connector.  

It looks like the previous method of using the API Break Inheritance is the only pracitcal approach.

[Pstork1]

If the user executing the Flow doesn't have 'Manage Permissions' permission I don't think you will find that you can do the REST call successfully.  You need to have that permission in the permission level assigned to you to be able to break inheritance and change the permission no matter how you do it.

[RezaDorrani]

Hi @jarodpearcy 

@Pstork1 is correct - rest api wont help either

Your challenge here is to trigger the Flow not in the context of PowerApps

What I would recommend is when user needs to trigger the PowerApps do not call PowerApps from Flow. Instead create an item in a hidden SharePoint list (all this list will do is trigger the Flow when item is created). Now you can have a Flow which gets called on item added and this Flow can run in context of the Owner account to modify permissions

Regards,

Reza Dorrani

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly

[jarodpearcy]

If I'm not mistaken, the permissions lie within the bearer token. The REST call contains a bearer token with FullControl permissions and is agnostic as to who is executing the call.  

That being said, I've executed the (2) REST call from the flow with correct URI's and they both return status code 200.  However, the permissions for the test user remain unchanged.  Everything looks perfect yet there is no change.

Call 1:
https://xxxxx.sharepoint.com/sites/Team%20Site/Expenses/_api/web/lists/getByTitle('Reimbursement Item')/items(4)/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)

OUTPUTS: 

Status Code: 200

Body: 

{

"odata.metadata": "https://xxxxx.sharepoint.com/sites/Team%20Site/Expenses/_api/$metadata#Edm.Null",

"odata.null": true

}

Call 2:

https://xxxxx.sharepoint.com/sites/Team%20Site/Expenses/_api/web/lists/getByTitle('Reimbursement Item')/items(4)/roleassignments/addroleassignment(principalid=20, roledefid=1073741827)

OUTPUTS: 

Status Code: 200

Body:

<?xml version="1.0" encoding="utf-8"?><d:AddRoleAssignment xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" m:null="true" />

[Pstork1]

But the bearer token is created using the context of the user logged into the site.  User's who don't have permission to change permissions on a SharePoint site can't change the permissions by making a REST call based on their login.  It just won't work.  The REST call itself may return a 200 status because the call was made successfully, but the change will be ignored if the user doesn't have the right permission level.  It wouldn't be secure if it worked differently.

[jarodpearcy]

The bearer token I'm using is being generated via an App Add-in with "FullControl" permissions.  It's totally agnostic as to who the user is.  When the App Add-in had "Read" permissions the REST call would fail with insufficient permissions.  When I changed the App Add-in to "FullControl" the REST call succeeded status code 200.

<AppPermissionRequests AllowAppOnlyPolicy="true">

    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />

</AppPermissionRequests>

[jarodpearcy]

Here is a summary of the approach I'm using.

Perhaps I need to rethink the approach.  The bottom line is that when a PowerApp user submits an item for expense reimbursement that they are no longer allowed to edit the item and if the submissions is rejected then they are once again allowed to edit the item so it may be resubmitted.

Is there a better approach than changing permissions on the item or a better way to instantiate the item permissions changes?

[Pstork1 · Accepted solution]

It could be as simple as changing the Flow from one started via Powerapps to one that is triggered by a change to the list.  Flows that are started by a trigger run in the context of the user who made the Flow.  If that is you and you have Manager Permissions that will all work with the Trigger.

[jarodpearcy]

I see.  I could use the SP 'Item Changed' connector and then check to see if the change was the submission status and then the Flow would run under my Ower permissions.

I'd still like to know why the REST calls with a bearer token from an App Add-In aren't having any effect.  When I was incorrectly targeting an Office 365 Group's SharePoint site the break inheritance REST call worked.  It created other complications but it worked.

[Pstork1]

I would assume the connector is overriding and supplying its own bearer token to remove that from something the user is required to handle when using a Rest call action.

[jarodpearcy]

No, the bearer token is imbedded in the header.  Of course there's a difference between a SP connector and HTTP REST API call.