jcr:RemoveChildNodes not working by itself | Community
Skip to main content
J
josephabraham
Level 2
October 16, 2015
Solved

jcr:RemoveChildNodes not working by itself

  • October 16, 2015
  • 3 replies
  • 1224 views

One for the AEM Geeks : 

From the useradmin screen, when we assign a "delete" privilege to a group for a particular node (say /content/dam/foo, a folder in this case), I noticed two privileges being assigned in the rep:policy node (jcr:removeNode and jcr:removeChildNodes). Hence I tried to check out the behavior of the system when only jcr:removeChildNodes prilvilege is applied. My expectation is that the user should be able to delete the contents within the folder "foo" but not the folder itself. However, this didn't work for me. Any takes on why this could happen?

 

FYI. I used the ACL Setup Service to apply the jcr:removeChildNodes privilege at the /content/dam/foo. Even after this, the user wasn't able to delete anything under "/content/dam/foo". 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by smacdonald2008

"All I would like to enforce is that they do not delete "foo" by mistake."

In this case - if you are concerned about a user of the group deleting foo - ie:

  • content/foo22/ (as shown in my examle to represent foo)

 

then simply remove the delete permission at this level of the JCR for that group. Keep delete permissions on any children. That is the way the product is intended to work as discussed in this topic i listed above.

 

If you are looking for an automated way to set these permissions (you do not want to use the Security tool as shown above), you can create a JCR event handler that would set these permissions when you create a node under foo22. 

3 replies

smacdonald2008
smacdonald2008
Level 10
October 16, 2015

When you set groups permissions - you can set the exact level in the JCR that you allow a member of the group to delete. For example, consider the following illustration. 

[img]JCRDelete.png[/img]

We have extended all members of this group to delete:

  • content/foo22/
  • content/foo22/foo44
  • /content/foo22/foo44/foo55 

If you do not want members of that group to delete the top level - you can change that in the permissions view. 

All of this is covered in this AEM doc topic:

http://docs.adobe.com/docs/en/aem/6-0/administer/security/security.html

J
josephabrahamAuthor
Level 2
October 16, 2015

Not really what I am looking for. 

I have users who have access to create and delete stuff under foo at the moment. All I would like to enforce is that they do not delete "foo" by mistake. A user may create ten folders under "foo" tomorrow. I do not want to add more and more rep:policy nodes (for each folder) each time a folder is created (manual or scripted) as this would eventually lead to performance bottlenecks

Hence, logically it would make sense to get rid of the jcr:removeNode privilege on "foo" while keeping the jcr:removeChildNodes privilege in place. 

smacdonald2008
smacdonald2008Accepted solution
Level 10
October 16, 2015

"All I would like to enforce is that they do not delete "foo" by mistake."

In this case - if you are concerned about a user of the group deleting foo - ie:

  • content/foo22/ (as shown in my examle to represent foo)

 

then simply remove the delete permission at this level of the JCR for that group. Keep delete permissions on any children. That is the way the product is intended to work as discussed in this topic i listed above.

 

If you are looking for an automated way to set these permissions (you do not want to use the Security tool as shown above), you can create a JCR event handler that would set these permissions when you create a node under foo22. 

Terms & ConditionsAccessibility statement

Loading footer...