Forum Discussion
Why delete permission is required to rename a document in SP Document Library?
Yeah, with a standard Contribute level sans Delete, the permissions mask isn't going to match what SharePoint is requesting to rename an item (0x28 or DeleteListItems + OpenItems). This is identical to what would occur on a file system over CIFS or local (NTFS); the operation is not a 'rename', but rather a move operation. A move, of course, requires the ability to delete the source file once the move has been confirmed.
And as noted in the article, SharePoint acts similar to a file system, hence acting like an Windows Explorer move operation.
Not really an answer to your "Why?" question, but this is by design
https://support.microsoft.com/en-us/help/2505742/contributor-users-are-not-able-to-rename-items-in-sharepoint-if-the-delete-permission-level-is-removed-from-the-contributors-group
- Link is now
https://support.microsoft.com/en-us/topic/dc4330c0-c1bd-59bd-ba4f-c1c0049809bb Yeah, with a standard Contribute level sans Delete, the permissions mask isn't going to match what SharePoint is requesting to rename an item (0x28 or DeleteListItems + OpenItems). This is identical to what would occur on a file system over CIFS or local (NTFS); the operation is not a 'rename', but rather a move operation. A move, of course, requires the ability to delete the source file once the move has been confirmed.
And as noted in the article, SharePoint acts similar to a file system, hence acting like an Windows Explorer move operation.
- Work around (not pretty)
Add a metadata column for rename (checkbox) and column for the filename (single line). Use a SPD workflow with either an impersonation step (2010) or an app step (2013). On change, if checkbox is checked update item and rename.
This isnt exact steps, but basically what you have to do.
We have a large example of this where delete had to be removed for Business reasons, which subsequently removed rename and move permissions. In our case, We built an app in NAPA that allowed users to browse the file structure, select a file, enter a new file name or select a destination folder and hit enter, which creates a new list item in a hidden list, and the workflow runs on that list item (spd 2013 with app step and "moveto" api rest call to rename in place)
Like I said, not elegant but effective
- Why not just create an "extended Contributor" permission level that includes the "Delete" individual permission?
