A recent client had a requirement that certain users were NOT allowed to delete files – but that they would be able to add, edit, etc.
The solution that was put in place involved the following steps :
- Create a new user role – Contribute Without Delete (within SharePoint)
- Copy the “Contribute” role
- Un-check the ability to Delete
- Add users to this role/group – within SharePoint
This solution works well – and people can’t delete – there is no ‘icon’ on the Ribbon or Context Menu.
BUT – and this is where the problem arises – people are getting errors.
- User-A is within Contribute Without Delete
- Uploads a document to a library
- Metadata screen is shown
- User changes the document name (or via Edit Properties)
- Click OK – and BOOM – Access Denied !
- This problem does NOT occur for other users – only those within the Contribute Without Delete role/group.
When a file is renamed in SharePoint, it is actually DELETED and ADDED with the new name.
As such, any users who do not have ‘delete’ permissions will get an Access Denied error – as shown.
This is the same as the Windows File System – within Windows Explorer – ie. consistent behaviour.
HOW TO SOLVE ??
Quite simply, the best approach is to NOT use the Contribute Without Delete role/group.
The discussion I’ve had with some colleagues has some merit :
- If a person is able to upload/edit, why NOT allow Delete
- If they accidentally delete, it goes into their own Recycle Bin
- If they empty it, it goes into the Site Collection Recycle Bin
- If a person should not be able to delete a file, perhaps have an area where they have READ ONLY permission – and can’t do any edits, ie. no renaming, etc.
It’s certainly an interesting scenario, eh ?
Rename = Delete + Add
I’ll have to talk it over with my client – and work out what they want to do !