Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

AEM User / Group permissions for subfolders

jwendling
Level 1
Level 1

Currently, we have the folder structure listed below. When I set up a permission group Group A with access to Company A, for this to work I have to include read access to the Team and Clients level folders. The issue I'm having is when a new folder for Company D is added to the Clients folder, Group A ends up having visibility into the newly added folder. Is there a way to avoid this?

 

  • Team folder (top-level folder in files)
    • Clients
      • Company A 
      • Company B
      • Company C
      • Company D (Newly added folder)
1 Accepted Solution
FreedomMarketin
Correct answer by
Level 4
Level 4

Good question and unfortunately, the answer is "not exactly."

 

Your issue is an ongoing governance issue as new Company folders are added.  The other solution provided will work as a one-time fix, but if you wanted to manage permissions every time a new Company folder was created you could do so through the normal /useradmin interface--there's no special benefit to directly editing the rep:policy node.

 

When we've had situations like this, we've found the best solution is normally to make the Company folders a top-level folder.  Then you can add read-access as new folders are added to appropriate groups (i.e. Group D gets access to Company D folder) without having to do deny permissions to all the existing groups to cancel the inherited read access.  This can get cluttered if you've got a lot of Company folders and some users get access to a lot of them, but it's the only way without customization that you can avoid a bunch of manual governance (and risk of inappropriate access if you forget to add all the deny nodes when you add a new Company folder).

 

The only other option without customization is to build really good governance processes.

 

The third option is to customize an event listener in the parent folder to automatically add deny nodes to existing security groups when a new child folder is added. This probably isn't too terribly hard, but I'll confess that we've never had a situation where the number of child folders was so unmanageable that this was worth doing.  It's the sort of customization that may require maintenance (and certainly regression testing) through patching and upgrades.

 

Hope this helps,

Beau

View solution in original post

3 Replies
diksha_mishra
Community Advisor
Community Advisor
Can you try re-applying Read Only permissions to Clients folder? That should reflect Read only on all the subfolders. If you still face issues, please share a snapshot of assigned user permissions.
BrijeshYadav
Level 5
Level 5

Add rep:Restrictions policy at /content/team/Clients. Here is an example of rep_policy.xml

 

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:ACL">
<GroupA
jcr:primaryType="rep:GrantACE"
rep:principalName="Group A"
rep:privileges="{Name}[jcr:read]">
<rep:restrictions
jcr:primaryType="rep:Restrictions"
rep:glob="/*/Company D*"/>
</GroupA>
</jcr:root>

 

FreedomMarketin
Correct answer by
Level 4
Level 4

Good question and unfortunately, the answer is "not exactly."

 

Your issue is an ongoing governance issue as new Company folders are added.  The other solution provided will work as a one-time fix, but if you wanted to manage permissions every time a new Company folder was created you could do so through the normal /useradmin interface--there's no special benefit to directly editing the rep:policy node.

 

When we've had situations like this, we've found the best solution is normally to make the Company folders a top-level folder.  Then you can add read-access as new folders are added to appropriate groups (i.e. Group D gets access to Company D folder) without having to do deny permissions to all the existing groups to cancel the inherited read access.  This can get cluttered if you've got a lot of Company folders and some users get access to a lot of them, but it's the only way without customization that you can avoid a bunch of manual governance (and risk of inappropriate access if you forget to add all the deny nodes when you add a new Company folder).

 

The only other option without customization is to build really good governance processes.

 

The third option is to customize an event listener in the parent folder to automatically add deny nodes to existing security groups when a new child folder is added. This probably isn't too terribly hard, but I'll confess that we've never had a situation where the number of child folders was so unmanageable that this was worth doing.  It's the sort of customization that may require maintenance (and certainly regression testing) through patching and upgrades.

 

Hope this helps,

Beau

View solution in original post