Details
Description
Currently the filter rules are not fully evaluated prior to applying ACLs (in rep:policy and rep:repoPolicy files). According to JCRVLT-372 this is a bug. The same is true for authorizable nodes (compare with JCRVLT-71).
The exact install behaviour is as follows (given that the ACHandling is not IGNORE):
ACL Path in Filter? | Effect | Example ACL Path(s) | Example Content Node Path(s) | |
---|---|---|---|---|
1 | Contained in filter | Installed | /testroot/node_a/rep:policy | /testroot/node_a |
2 | Not contained in filter, but ancestor is contained | Installed | /testroot/secured/rep:policy | testroot/secured |
3 | Neither path nor ancestor is contained in filter | Not Installed | /test2/rep:policy | /test2 |
4 | Path is not contained in filter, ancestor is not contained either, but node affected by ACLs is contained | Not Installed | /testroot/rep:policy | /testroot |
The example columns assume the following filter.xml
<workspaceFilter version="1.0"> <filter root="/testroot"> <include pattern="/testroot/secured"/> <include pattern="/testroot/secured/jcr:content"/> <include pattern="/testroot/node_a(/.*)?"/> </filter> </workspaceFilter>
Attachments
Issue Links
- is related to
-
JCRVLT-372 Clarify import and export behaviour for rep:policy nodes not contained in filter rules
- Resolved
- relates to
-
SLING-10760 Converter ignores access control content and users/groups in .content.xml files
- Open
-
JCRVLT-71 Allow creation of ancestor user nodes when they are not explicitly included in a filter
- Closed
- links to