Edit Permission Allows Deletion

[Andrew Stout]

Is it expected that when sharing documents via OneDrive for Business and assigning "Edit" permission, those users can delete the documents as well?  This is a bit concerning as there doesn't appear to be a way to grant someone the ability to edit a document without also allowing them to delete that document from the original users' OneDrive.  

To confirm this:

1. Open an Office document that has been shared with you in your browser.
2. Click on the name of the document owner in the upper left of the screen while the document is open in the browser.  This takes you to that users' OneDrive for Business library and displays any documents that they have shared with you.
3. Select the document(s) and click Delete.

This moves the document into the original owners' recycle bin, which prevents further access by anyone they have shared it with.

[#2 · Accepted solution]

IMHO this is how it works now...since you have the Edit permission that is SharePoint permission behind the scenes, you are a collaborator in the file and you can delete it

[#3]

@jcgonzalezmartinis correct, as always.

When you choose to give edit rights while sharing, you are actually assigning behind the scenes the SharePoint "Contribute" permission level, which allows users to "view, add, update, and delete list items and documents" (from https://support.office.com/en-us/article/Understanding-permission-levels-in-SharePoint-87ecbb0e-6550...).

Unforunately there is not a permission level which allows users to edit but not delete documents.

[#4]

While I appreciate the replies, I can tell you that our users will reconsider using OneDrive for Business to share files with others when they know that this can happen.  I am sure that there are plenty of scenarios where allowing others to delete your files makes sense, but not providing a simple way to allow editing without deletion will make users uncomfortable with the platform.

[#5]

The delete right being part of the "Edit" permission isn't the biggest issue in our environment.  Instead, our biggest issue is people with "Edit" permissions have the right to change permissions on the document/library/list/site.

IMHO, when Microsoft made "Edit" the default with SP2013/SharePoint Online, it was a huge mistake.

[#6]

Totally agree with you.  EDIT permissions SHOULD NOT allow permission controls.  This is undermining our ability to use ODFB since users (content owners) do not have control over access to their files if they collaborate.

I assume the thinking behind this behavior is that if someone can edit a document, they can download and share it -- but the same is true for READ as well and READ does not have permission controls.

So IDK what they heck the thinking is.

Read = Read

Edit = Contribute (don't like the delete list permission, but understand it's probably more about list control than list delete)

Full Control = Contribute + Permissions control

Just like it has been for years.

[#7]

@Deleted @James Redmore

Couldn't the problem be solved simply unchecking "Allow members to share the site and individual files and folders" in Access Requests Settings?

[#8]

Oh wow, I wasn't aware of that setting. I'll test that and confirm. thank you!

[#9]

Yes, you're right @Salvatore Biscari -- My problem is with the default settings.  The default of this setting should be "off" and the default permission for the members groups should be contribute.  The subtle change from "contribute" to "edit", combined with the default of allowing members to share, was a drastic change.

Even better would be an option in the admin center to set what the default should be. We have 7,000+ SharePoint sites (organized into 800+ site collections), so changing a default setting is a labor intensive activity for us.

[#10]

@Deleted

My 2 cents:

1. At library level you can stop inheriting permissions and change the permission for the members groups to contribute. I would not advice to make this, because IMHO is better to leave the default permissions alone, but apparently it can be done. I would be curious to know if it has unwanted/adverse consequences...
2. Mass disallowing members to share could be done by PowerShell. See https://techcommunity.microsoft.com/t5/SharePoint-Developer/Changing-the-quot-Allow-members-to-share-quot-SharePoint-site/td-p/18562

All this said, I agree with you that a global option in the admin center would be much better. 😉

[#11]

Thanks again Salvatore, we found the setting and looped our OneDrives to disable the settings -- users can turn them back on if they choose, but we prefer the more secured profile by default. This is so much better -- feel like I'm back in a comfortable old pair of jeans! cheers

Allow members to share the site and individual file and folders

Allow members to invite others to the site members group.  <Site> Members.  This setting must be enabled to let members share the site.

Connect-PnPOnline -Url $url

    $RootWeb = Get-PnPWeb -Includes MembersCanShare
    $SubWebs = Get-PnPSubWebs -Recurse
    $AllWebs = @()
    $AllWebs += $RootWeb

    $RootURL = $RootWeb.Title
   
    Write-Host $RootURL

    foreach ($SubWeb in $SubWebs) {
        $Sub = Get-PnPWeb -Identity $SubWeb -Includes MembersCanShare
        $AllWebs += $Sub
    }

    foreach ($Web in $AllWebs) {
   
        $WebTitle = $Web.ServerRelativeUrl
       
        if ($Web.MembersCanShare) {
            $Web.MembersCanShare = $false
            $Web.Update()
            $Web.Context.ExecuteQuery()
            Write-Host "$WebTitle - MembersCanShare Disabled" -Fore Yellow
        } else {
            Write-Host "$WebTitle - MembersCanShare Already Disabled" -Fore DarkCyan
        }
       
    }

[#12]

I'm not totally happy with either EDIT nor CONTRIBUTE. While EDIT is often to broad, CONTRIBUTE has too either little (when removing the DELETE permissions from this level) or too much (when leaving the DELETE permissions). 

Therefore it is currently not possible to have a library where users can upload + rename, but not delete, since DELETE is necessary to RENAME a file ...

[#13]

Interesting script, but as advised by Salvatore you are changing a default behavior in ODFB security. I understand your scenario but I also advice, even in this scenario, not to change default configurations in ODFB just to avoid any unexpected side effects :-). Of course, If you have everything documented and a rollback plan, you are just fine to go back to the previous situation...as an example in a test tenant a while ago I was doing some tests about chaning default security configuration in the ODFB of one of my tests users and now I have some unexpected behaviors when sharing files that I know are coming from this change...since I did my tests in a test tenant, I'm fine...I wouldn't if I have done in a production tenant

[#14]

While it seems that this is how the permissions currently work, this isn't a solution to the question/problem.

Is there any update regarding wether or not an additional permission setting exists (or can exist in the future) that would allow for read/write permissions without the ability to delete files to non-owners? This is the problem, and I see no solution posted at this time.