Content permisisons check works incorrect during "Duplicate to" action

[PeterKvayt]

Which Umbraco version are you using?

15.3.0

Bug summary

I am developing custom granular permissions.

My custom granular permissions allow for assigning permissions on a particular document type. So, e.g., I can allow publishing for all doc types except the specific ones.

During development this I have faced the issue related to the "Duplicate to" action.
I have dived into the code and found out that for the "Duplicate to" action, we request permissions for 2 nodes: for the node that we are trying to duplicate and the other one for its parent.

With the help of your AI assistant, I understood that we use parent here to determine whether the user has permissions to create a node under the parent or not:

So, if we use the parent node to find out that the user has permissions to create a node under the parent node, I think we have to use Umb.Document.Create for the parent and Umb.Document.Duplicate for the node being duplicated.

Currently, Umb.Document.Duplicate permission is used for both the parent and the duplicated node.

I think it is wrong, and we should check Umb.Document.Create for parent and Umb.Document.Duplicate for the node being duplicated.

Specifics

No response

Steps to reproduce

1. Create the parent node
2. Create the child node under the parent node
3. Put breakpoint here
4. Duplicate child node under the parent node
5. Look at the debug info

Expected result / actual result

Expected: there are should be 2 checks: one for parent with Umb.Document.Create, one for duplicating node with Umb.Document.Duplicate
Actual: there is only one check for both nodes.

[github-actions]

Hi there @PeterKvayt!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[AndyButland]

I'm not sure on this one @PeterKvayt - whilst I agree with your logic and certainly don't want to argue with the AI, and if we were building from scratch I think the way you describe it would make most sense. But the downside is this is changing how the system behaves - I've checked and going back to older versions it's the same.

That would be OK if the current setup was obviously wrong, but I'm not sure it is. I think you could conceive a situation where you want to restrict an editor from creating new content, but you might allow them to copy and adapt some partly prepared content items. So by giving an editor "Copy" or "Move" permissions, you are explicitly giving them the rights to both copy the source and "create" at the destination.

[PeterKvayt]

@AndyButland

Okay, I want to describe my case more closely.

Let's say we have 2 content types: Root and Child.
Child allowed under the Root.

I have 2 user groups.
One, let's say Super Managers, has the following permissions:

• Umb.Document.Create/Read/Update/Publish for Root content nodes (Create means that they can create nodes under Root nodes)
• Umb.Document.Read/Update/Publish/Unpublish/Delete/Duplicate for Child content nodes (under the Root).

The other one, let's say Local Managers, has the following permissions:

• Umb.Document.Create/Read for Root content nodes (Create means that they can create nodes under Root node)
• Umb.Document.Edit/Publish/Unpublish/Delete/Duplicate for Child content nodes (under the Root).

So when we check the parent and node for Umb.Document.Duplicate permission, then it leads us to the following situation: Super managers and Local Manages do not have the ability to create a child node duplicate, because they do not have the Umb.Document.Duplicate on Root doc type, but they have the Umb.Document.Duplicate permission for Child and Umb.Document.Create for the Root doc types.

I know that we have had this behavior since Umbraco 10 (I have not looked further), but maybe we could change the behavior in the future?
For my case, I think I will find a workaround (maybe I will override the default umbraco CopyController with my custom or I will create a custom copy action, I do not know).
But I think it is worth thinking about it.

P.S.: I think I did not fully understand your example

That would be OK if the current setup was obviously wrong, but I'm not sure it is. I think you could conceive a situation where you want to restrict an editor from creating new content, but you might allow them to copy and adapt some partly prepared content items. So by giving an editor "Copy" or "Move" permissions, you are explicitly giving them the rights to both copy the source and "create" at the destination.

It will be great if you bring some details to it.

Many thanks for the response.

[AndyButland]

I think you could conceive a situation where you want to restrict an editor from creating new content, but you might allow them to copy and adapt some partly prepared content items. So by giving an editor "Copy" or "Move" permissions, you are explicitly giving them the rights to both copy the source and "create" at the destination.

It's maybe not very likely, but there a lot of ways to use Umbraco! I was getting at the idea of one "power editor" that has permissions to create content, perhaps with some very complex grid structure; and another, restricted one that only has permissions copy existing content and adapt it by changing a few fields, but not create from scratch.

In that scenario you'd give the restricted editor "copy" permissions, but not "create".

[PeterKvayt]

Oh, now I see your point of view, thank you.

Based on your response, the situation appears to be as follows: when a user without "power editor" rights doesn't have permission to create content, they can still copy and modify existing content. But doesn’t that effectively allow them to create content from scratch, just in a more roundabout way?

What’s stopping them from simply duplicating existing content and overwriting everything? It’s essentially the same outcome—just a less convenient method of creating new content.

Therefore, granting the Umb.Document.Duplicate permission without Umb.Document.Create effectively allows users to create content, albeit indirectly. It would make more sense if duplication required both permissions. That way, Umb.Document.Duplicate governs only the ability to duplicate, while Umb.Document.Create clearly controls the creation of new content, keeping responsibilities distinct.

We can also consider this from a different perspective. Instead of requiring both permissions explicitly, we could maintain the current model where only Umb.Document.Duplicate is needed to duplicate content. However, during the duplication process, the system should internally check for both Umb.Document.Duplicate and Umb.Document.Create.

This logic could be implemented somewhere in the codebase—perhaps in Umbraco.Core.Services.ContentPermissionService, just as a suggestion. The logic would work like this:

• Check for both Duplicate and Create permissions.
• If the user has only the Duplicate permission: assume that duplication inherently grants the ability to create, even if Create is not explicitly assigned.

This approach ensures we’re checking the correct set of permissions (Duplicate and Create) while preserving the current behavior —users don't need to be granted Create explicitly in order to duplicate content.

It’s just an idea, but it allows us to enforce a more consistent and logical permission structure without disrupting existing workflows.

[AndyButland]

All good points @PeterKvayt - let me take it to the team to decide how to proceed. My only reluctance to changing this to what I agree does seem more logical is if you could argue the current setup is reasonable, and we'd then be changing behaviour from what Umbraco has done from some time.

[iOvergaard]

Fixed with #19303 and will be included in V16.