07-04-2019 07:24 PM - edited 07-04-2019 07:26 PM
07-04-2019 07:24 PM - edited 07-04-2019 07:26 PM
We had a situation where an end user accidentally deleted thousands for files under a SharePoint document library via OneDrive.
The document library itself is accessible to everyone within the company.
Is it possible to prevent users from deleting files within a document library and all subfolders?
All users currently have "Edit" permissions allowing users to add, update and delete all items. There doesn't appear to be a permission level that allows all this except for delete.
07-05-2019 03:03 PMSolution
08-11-2019 02:16 PM
Sure, with the Edit right, you can edit the file or modify its metadata no problem. However, by renaming it, it seems the system must delete one version to re-create the new version with the new name. This must be done with the Delete right.
There has been some discussion on that:
Forced me to do a few acrobatics in my application cause I wanted to prevent users from deleting their files (and those contributed by others) but also allow them to rename the file.
09-03-2019 07:33 AM
11-20-2019 06:46 AM
@telecaster I am also facing this same issue in that I'd like to prevent users from deleting files. However, it also seems to prevent their being able to move files.
Could someone please confirm for me those two are also related. Also, what else might be affected if you do not allow delete?
Anyone know of a User Voice to vote for this option. It seems to be a frequent request -- to prevent delete but allow other options.
Thank you in advance for your help, everyone!
02-12-2020 05:40 PM - edited 02-12-2020 06:38 PM
I am not an Admin of our SharePoint instance, but I do have the ability to create sub sites. I can’t create my own unique permissions either. I have to work within the defaults I’m provided. I also don’t want the Users deleting their folders on which they can Contribute as all the permissions on the folder go with the folder and it’s a headache to fix - maybe even detrimental depending on what files are lost and the retention policies in place. The “can’t be done” answer is less appealing to me than a slightly tedious solution that works.
One option to consider trying - that works for me - is to:
1.) Place a tiny txt file in the Member (User) [or Group folder] and then as Owner “Do not share” the txt file so it is only visible to the Owner. In other words, the Owner has Full Control on the txt file, and no one else has any access - therefore they don’t even see it in their folder on which they have Contribute permission. Then
2.) Right-click on the txt file as Owner and “Check out” the file.
It’s a bit of a hack, but if the Member with Contribute rights tries to delete the folder either intentionally or by accident (even when appearing empty) they will be told the folder has a file checked out for editing and they can not delete the folder.
If you have sub folders within the folder you wish retained, then placing this _.txt or do_not_delete.txt file in the sub folder will prevent easy deletion of both the sub folder and (all enclosing) folder(s). The Member’s file actions (i.e., create, rename, delete, etc.) on their own files are otherwise unaffected as only the txt file’s access is impacted.
The obvious downside is this ”fix” takes clicks within each User “Contribute” folder, but depending on the number of Users and folders the Owner has within the site, it may be worth the time spent and help you rest easier knowing the folder‘s aren't easily deleted.
If you have Admin control over the site I imagine you should be able to come up with a better way (i.e., faster and less tedious way) to achieve the same outcome.
04-14-2020 07:20 AM
@Jeff_Nowak_Purdue_U_FW Hi, I liked your solution to this problem albeit, as you said, rather tedious to implement. The main problem would be remembering to insert the text file in every newly created folder.
I'm interested to know whether you found another solution?
04-15-2020 05:12 PM
A bit of time has passed since this question, however in my experience the granular 'delete' permission is related to the following actions someone might want to do:
NB: as aforementioned by others in this post
When I implemented a delete restriction in document library where I wanted more control I created a workflow to be manually run which allowed someone to provide the new name of the file. It then renamed the file using a specific account that had elevated rights to the library.
That was implemented on-premise and I am yet to re-create this online, however I imagine the logic would work the same.
Hope this helps.
04-22-2020 08:48 PM
That's a very good question. Moving files is on my radar as a function I need to test for two reasons:
- I like maintaining a single version of the truth, and
- in some environments people keep everything regardless of being deleted, which adds to total capacity
Will let you know how I get on. Once working I will test it with the custom permission level.
by joannalynne on May 26, 2020
by Sam1209 on May 26, 2020
by rautchetan27 on May 25, 2020
by miridab on May 25, 2020
by Mark Kashman on May 26, 2020
by Mark Kashman on May 19, 2020
by SPDev_Support on May 06, 2020