[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303658#comment-17303658
]
Eric Norman commented on SLING-9871:
------------------------------------
[~bdelacretaz] If we are going to support ACL ordering then don't see any
reason why we would want to exclude the first, last and numeric order options.
If you don't like those then you can just not use them, but I see no need to
limit that choice for people who would like to do such things. Plus it makes
it easier to migrate from "Sling-Initial-Content" to repoinit if there is
parity here.
For example, in a truly modular aggregation, you may have no idea what
principal your ACE would need to be before or after. For example, suppose you
want to deny the everyone principal read rights to some node in a "base
feature" and then allow read rights for certain people in other "module
features" that may or may not exist in the final aggregate feature depending on
the choices of the person assembling it. In this case you want the
everyone-deny ACE declared in the "base feature" to be the first one but you
don't know the names of the other principals that may arrive via the "module
features" for other ACEs so it would be impossible for the repoinit in the
"base feature" to declare a "before X" clause and you would be forced to
duplicate an "after everyone" clause in the repoinit for each of the "module
features" which could be redundant and annoying.
[~ashishc] I haven't looked that closely at the reproinit Acl code to see if it
does something different, but if I recall correctly, the handling of setting
permissions in org.apache.sling.jcr.jackrabbit.accessmanager and
org.apache.sling.jcr.contentloader currently attempts to merge the permissions
settings for each principal into a single ACE per principal. Do your
requirements need more complexity, where a principal may have more than one ACE
with (for example) different restrictions or something that need to be in some
specific order? I haven't put much thought into it since I haven't needed that
capability, but I'm not sure how we would be able to uniquely identify which
ACE is which in that scenario for the purpose of ordering them. For that use
case it seems to me that there would need to be some way to store an "id" with
each ACE that you could reference?
> Specifying order of ACEs through repoinit directives
> ----------------------------------------------------
>
> Key: SLING-9871
> URL: https://issues.apache.org/jira/browse/SLING-9871
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Ashish Chopra
> Priority: Major
>
> As of writing this, repoinit processor (among other things not relevant to
> this JIRA) collects {{create path}} statements and {{set ACL}} statements
> declared in all the feature-models applicable to feature-aggregate under
> consideration.
> Upon repository initialization, it applies all the {{create path}}
> statements, followed by all the {{set ACL}} statements. However, the order in
> which {{set ACL}} statements declared across feature models are applied isn't
> defined (currently, it seems to be based on feature-model-name,
> alphabetically ascending).
> This causes issues at times because we want the order of the ACEs to be
> maintained (e.g., "deny"s for everyone at a given path must be the first ACE,
> followed by "allow"s for specific, non-system-user principals)
> Repoinit should be able to support this requirement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
