ACL Permission Issue

[test1234567]

I have encountered an issue while updating the page properties. There is a deny rule for everyone group as shown in the below screenshot.

Users belonging to a specific group are unable to update page properties, even though they have Read, Modify, Create, and Delete permissions for the required path. The necessary permissions for /content have been granted, but these users continue to receive an error.

To resolve the issue, I added the jcr:modifyProperties privilege, after which the error was resolved. However, I noticed that jcr:modifyProperties was not listed among the original privileges, and I verified the rep:policy node as well.

Interestingly, when I remove the rep:write privilege and add only jcr:modifyProperties, I can see the entry, which suggests that jcr:modifyProperties is an aggregate privilege of rep:write. This raises the question: why did it not work when rep:write was granted, and why was the explicit addition of jcr:modifyProperties required?

Furthermore, I do not see an entry for jcr:modifyProperties among the assigned privileges by default.

[Karishma_begumSh]

Hi @test1234567 

The issue occurred because of a deny rule applied to the everyone group under /content, which restricted certain property modifications. Although the specific user group had Read, Modify, Create, and Delete permissions with rep:write, they were still unable to update page properties.

To fix this, I explicitly added the jcr:modifyProperties privilege, after which the users were able to update the page properties successfully.

The reason this was necessary is that rep:write is an aggregate privilege, which internally includes

jcr:modifyProperties
jcr:addChildNodes
jcr:removeNode
jcr:removeChildNodes

However, when a deny rule is in place (especially for everyone), it can block specific sub-privileges inside the aggregate — even if rep:write is granted elsewhere. In this case, the deny rule effectively prevented property modifications.

By explicitly granting jcr:modifyProperties, I created a direct allow privilege, which overrides the deny restriction for property updates.

Also, jcr:modifyProperties does not appear by default in the permission list because it is part of the aggregate rep:write privilege. It only appears when explicitly added.

Hope this helpful:)

Regards,

Karishma.

[test1234567]

Thank you for your inputs. I understand that jcr:modifyProperties is part of the aggregate rep:write permission, and therefore it won't be visible in the permission list. However, I would like to know how the permissions are being resolved for this issue. Can you tell me where these permissions are stored—are they kept somewhere in the registry and not visible on the rep:policy node?
I just want to confirm whether the permission (jcr:modifyProperties) I have added is being stored somewhere and handled by the services, even though it is not visible in the permissions console.

[test1234567]

Upon further investigation, I found that jcr:modifyProperties did not resolve the issue. The root cause appears to be related to the order of ACL entries. If "allow" is the last entry in the list, everything works as expected. However, if "deny" is the last entry, I receive an error when updating the page properties.

I'm not sure what additional permissions must be granted so that it works regardless of the order of the ACL entries. Adding permissions at a deeper level(i.e. /content/project/test) is one option, but I would prefer to add the necessary permissions directly to the same path, i.e. /content.