current setup: Using Netcentric's Access Control Tool for managing users/group permissions
I think my requirements are best explained with an example. I want to use Netcentric ACL to manage this if possible.
I've been searching the net but can't even see discussion on the topic
Thanks for the assistance.
In edit mode, members of group X has edit access to existing pages in path /content/mysite/en/about with the following access/restrictions
- allowed to edit any existing component that are already on the page
- allowed to move or delete any component that's already on the page
- not allowed to insert any component into the page. For example, if they delete a button component on the page, they cannot put it back.
I assume this scenario is for the case of dynamic templates with initial content set up, which should be filled only by the editor but not structurally/changed adapted other than not using some of the initial content, am I right?
Otherwise, I'd wonder about the actual use case validity, and if maybe policies are a better solution.
Still, it is possible to achieve what you want:
With the ACL tool, you can use the repository privileges as well as the AEM rights. To achieve what you want, you need to use the repository privileges level.
If you grant someone edit but not create AEM rights in a certain folder, actually two ACEs are created: One granting you modification rights on the page, one granting you creation of subNodes below the jcr:content. This entry is responsible for the ability to add components as well. If you create these two lines manually and only add the privileges responsible for removing nodes, you should be fine.
The two ACE definitions would look as follows (written from memory, typo-prone):
- path: /content/mysite/en/about
privileges: jcr:versionManagement, jcr:modifyProperties, jcr:read, jcr:lockManagement, jcr nodeTypeManagement
- path: /content/mysite/en/about
privileges: jcr:removeChildNodes, jcr:removeNode
With this setup, the corresponding user would NOT have the rights to create additional pages in this section; but I would assume that's okay given it is a user with very limited rights. If instead page creation should be possible but not adding components to the page, you would have to work with deny statements in the rep:glob rule - I'd try to avoid that (and question the use case). Also, you might have to add crx:replicate for publishing rights - again, unlikely for such a limited user group.
Hello. I tried you're suggestion (privileges: jcr:removeChildNodes, jcr:removeNode) and I cannot add/edit/delete components. I cannot do anything on the page.
If I give "jcr:addChildNodes" access, I can edit and delete existing components (which is want I want) but I can also add new components (which is NOT what I want).
I had a look at the various JCR privileges (https://sling.apache.org/documentation/bundles/managing-permissions-jackrabbit-accessmanager.html) and nothing stands out.
Any ideas? Thanks!
we perform something of similar in our project but we cannot use nothing of out of the box.
We perform a customization that allow us to specify which group could make some changes on specific component by defining something like below:
- sling:resourceType = "granite/ui/components/foundation/button"
- sling:resourceType = "myapp/components/renderconditions/group"
- groups = ["administrators"]
Let me know if you need more details.
Please take a look on the below blog post. This might help you.
Note : Script is working on 6.4.5, we have similar requirement to disable insertion of components but have to allow edit/update/delete, we able to successfully achieve the desired functionality by using the above blog post as reference.
I checked the configuration I submitted (as stated, I only wrote it down from memory, sorry). The issue seems to stem from the fact that there is a render condition used which hides the edit UI if insufficient ACLs are given - including the lack of create/delete paragraphs. Although the ACL setting is correct, the UI does not adapt accordingly.
The reason is the render conditions in the components, e.g. for the edit button at /libs/cq/gui/components/authoring/editors/clientlibs/core/js/edit/ToolbarActions/edit.ToolbarActions.EDIT.js which is checking the pageInfoHelper.canModify().
The information for that is coming via the pageInfo object, rendered by the com.day.cq.wcm.core.impl.servlets.PageInfoServlet. I'm afraid the servlet only knows the AEM rights (Read, Modify, Create, Delete, Replicate, ACL_Read, and ACL_Edit) and therefore doesn't distinguish between can edit, but not add components.
So you will have to roll with the UI customizations as outlined above; but the ACL settings enforce that the rights actually reflect what you allow in the UI.