Forum Discussion
Why delete permission is required to rename a document in SP Document Library?
Hi,
We manage our controlled documents in SPO and for contributors we give only contribute without delete permissions. Now the problem is, due to this permission level they are not able to change the document name via Edit Properties. Why is it so and is there any workaround for this? Thanks.
-Prashant.
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
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?
Yes there is a work around to solve this problem which I've done already,
you can simply add the following javaScript to watch DOM changes in your master page, to remove delete option for (document, folder, workflow, etc...) .
I wrote this code to remove "delete" and also to deactivate delete action from Keyboard if document was selected and"delete" button was pressed, without disabling delete button from being used in the web page (ex. text boxes, text areas, etc..), and this can be done by overriding confirmation method "window.confirm".
The attached screen shots shows the output after editing master page and publishing.
You can add the following script directly under the <body> tag in your master page html.
<script type="text/javascript">//<![CDATA[
var mutationObserver = new MutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
var objDelete = document.getElementById("ID_DeleteDocItem") || false;
var objDeleteItem = document.getElementById("ctl00_PlaceHolderMain_ctl00_ctl00_toolBarTbl_RptControls_diidIODeleteItem_LinkText") || false;
var objDeleteVersions = document.getElementById("ctl00_PlaceHolderMain_MngVersionToolBar_RptControls_diidDeleteVersions_LinkText") || false;
var objDeleteItem2 = document.getElementById("ID_DeleteItem") || false;
var objDeleteUserFromSCollection = document.getElementById("ctl00_PlaceHolderMain_UserListForm_ctl00_ctl00_ctl00_toolBarTbl_RptControls_diidIODeleteItem_LinkText") || false;if(objDelete){
var firstParent = objDelete.parentNode;
firstParent.parentNode.removeChild(firstParent);
}
if(objDeleteItem) {
var firstParent = objDeleteItem.parentNode;
firstParent.parentNode.removeChild(firstParent);}
if(objDeleteItem2) {
var firstParent = objDeleteItem2.parentNode;
firstParent.parentNode.removeChild(firstParent);
}
if(objDeleteVersions){
var firstParent = objDeleteVersions.parentNode;
firstParent.parentNode.removeChild(firstParent);
}
if(objDeleteUserFromSCollection) {
var firstParent = objDeleteUserFromSCollection.parentNode;
firstParent.parentNode.removeChild(firstParent);
}
});
});mutationObserver.observe(document.documentElement, {
attributes: true,
characterData: true,
childList: true,
subtree: true,
attributeOldValue: true,
characterDataOldValue: true
});
window.confirm = function(message) {
if(message.indexOf("Recycle Bin?") != -1){
return false;
} else {
var responseConfirm = prompt(message, "Confirm");
if (responseConfirm != null) {
return true;
} else {
return false;
}
}
};
//]]>
</script>
