I had a recent complaint from a customer using our K-Docs Approve product for document approvals. I have waxed lyrical as to why the standard OOTB feature for document approvals are inadequate and why Power Automate is not the answer (What’s Missing in SharePoint Document Management) which provided the driver to build something better.

The Problem

The problems comes when Content Approval is enabled for a document library and a user with Edit level permissions tries to relocate a document to another folder.

If you need a primer on Content Approval and Versioning in SharePoint, you could do worse than to read my post on the subject at SharePoint Document Version Control and Content Approval works but…

When Content Approval is enabled but a user without Approval permissions tries to relocate a document to another folder, they are met with a nasty error message, like the one below.

Inelegant as this message might be (and darn right scary to users) we can readily see that the problem is down to permissions.

This doesn’t make sense to users because with Edit permissions then can upload documents and the can copy the document to another folder just fine, so why can’t existing documents be relocated?

The Cause

It does (sort of) make sense when you throw the query into Copilot.

I think Copilot has gotten the order wrong though. I think the order is more likely to be:

• Copy to target folder
• Reapply metadata (which, with Content Approval enabled, means setting the Approval Status)
• Delete source document from source folder

Without the necessary permissions, it fails at step 2 then of course the source document never gets deleted. My guess is that Steps 1 and 2 are bound together in an atomic action and hence why we don’t end up with a copy in the target folder.

Anyway, the point is that it fails and fails inelegantly in my opinion – although at least we got told that there was a problem.

What Microsoft should have done

To me (and my customer in question) moving documents in this scenario should be supported. Afterall, we are not seeking to change the approval status, but merely to relocate a document and one would expect that edit permissions should be sufficient to achieve this.

I can’t help but feel that Microsoft could have found a way to code around this rather inconvenient annoyance. And if they felt that this couldn’t be achieved, they might have at least found a way to disable the Move To functionality for a scenario in which they can easily predict will fail.

Workarounds

There aren’t any perfect workarounds for this, as far as I can see ☹, but here is what I have considered:

Copy rather than move

We might copy the document to the target location and then delete the source document. That would work, but apart from it relying on the user to complete both sides of the transaction separately, we end up with a new document instance with a separate item Id and unique Id and this will likely break any permalinks that might be pre-existing for the source document.

Crank up user permissions

When users need to relocate documents we might just increase there permissions so that they have the approval permissions they need to result in a successful outcome. This works better but totally undermines the whole point of enabling Content Approval in the first place.

I guess this is a workable strategy if the plan is to conduct an extensive re-organisation as a one-off exercise. The idea is to temporarily increase the permissions assigned to editors (or a sub-set of them), let them do what they need to do and then reset their permissions afterwards.

However, this means that you need to get a user with full control involved and it’s a bit ugly as it would all too easy to forget to reset permissions.

Disable Content Approval and re-enable it afterwards

Yes, this also works but with the same problem as above in that it is too easy to forget to reset thing afterwards and it has the downfall that we open a window when Content Approval is disabled for the library. This is because Content Approval is a library settings. At least with the upping-permissions approach we can selectively target who is empowered, if we simply switch Content Approval off we lack all such finesse!

Microsoft bonkers again!

I am aware that bonkers might be a peculiarly British term that may not be in everyone’s lexicon. It means crazy, insane or mentally deranged – that last definition might be taking things a bit far, so I’ll settle for crazy!

So why am I saying Microsoft are crazy? Well, they of course just fix the problem, but what I am calling out here is the gaping hole that opens when we use Microsoft’s default Permission Sets.

Let me explain, the default Permission Set for a Site Member is Edit. Assuming that the standard settings have not been altered, this means that Editors also have the Manage Lists permissions. This means that an Editor can change the library configuration settings, including the ability to enable or disable Content Approval.

So Microsoft provide us a default position where and Editor cannot relocate a document in a library where Content Approval is enabled (as we have seen) but they can easily just switch Content Approval off, and SharePoint will happy let them relocate documents at will.

If that’s not a bonkers configuration, I don’t know what is – made all the more bonkers because it is the default position!