Allow to validate some best practices

[ghenzler]

In our projects, we use fragments that group the actual permissions on the content, the actual groups that user administrators for a tenant add users to (let's call them roles) are non-fragments and are just member of one or multiple fragments. This way the user admins never get to edit a role that already has members. It would be nice to validate that behaviour (if configured) automatically:

• roles should never be used in isMemberOf and should never use "members"
• roles and fragments for one project should reside in different directories (so only the actual roles can be changed, the fragments are only adjusted by the AC Tool!)

to distinguish what is a role and what a fragment, the algorithm could check

• either for a name convention (e.g. name.startsWith("fragment-"))
• or automatically derived assuming that all groups that are underneath a path that can be changed by user admins in the system are roles and all other groups are fragments

The first ist probably the better (easier to understand) approach

[mtstv]

I have in my project technical groups (your fragments) and user groups (your roles). They placed in the different folders under
/home/groups/tech
/home/groups/usergroups
User Admins can't see the tech groups and only can edit the user groups. That was realised by setting ACEs under /home/groups, /home/groups/tech and /home/groups/usergroups.

Technical groups are not only fragments, because it is a bed naming for some technical groups. I have for example Basis Content Editor (base_ce), Basis User Administrator (base_ua). Both groups combine the access to AEM tools (AEM GUI & Backend servlets) and AEM content area (functional content root ex. /content/catalogs, /content/dam/common, ...)

roles should never be used in isMemberOf and should never use "members"

It is not clear for me why you want to deny to use "isMemberOf" and "members" properties and deny the assigning of roles to tech groups during the execution of ACL Tool? I use it already to assign all my user groups (role) to other tech groups.
You can define the JCR path where to create any of groups, you can also define whether role should be a member of some tech group. It is flexible and good.

[ghenzler]

roles should never be used in isMemberOf and should never use "members"

@mtstv the driver here is that you don't want any group members in a group like myproject-content-editors - if you for example just reused the group myproject-content-editors in myproject-content-admins (using memberOf) to give all project admins the editor rights as well (without using a fragment), then user admins see myproject-content-admins in the list of members of myproject-content-editors when they try to assign users to myproject-content-editors (when this initially should be only an empty list).

[mtstv]

user admins see myproject-content-admins in the list of members of myproject-content-editors when they try to assign users to myproject-content-editors

I think it depends on how you configurate the hierarchy of your group membership. If you don't want any groups in some other groups you can configurate group membership in other ways, for example to define a basis content admin group only for content admin groups and a basis content editor group only for content editor groups. But if some admin did a mistace, the execution of ACL Tool will delete wrong membership. Am I right?

[mtstv]

In my projects I separated the tech groups from user groups and also created a tenant structure with ACEs under /home/groups/usergroups/brand/market/site for each user admin group.
As result any user admin group of some tenant can only modify the user groups of own tenant (to assign an user to groups where he has write access) and can't modify any tech group.