[ 
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301793#comment-17301793
 ] 

Bertrand Delacretaz commented on SLING-9871:
--------------------------------------------

bq.  Re-ordering the ACEs has been done for many years...

Agreed but I think that's on a "local" basis, but here I'm afraid we might be 
introducing possibly complicated orderings that would depend on repoinit 
fragments defined in other Sling Features when those are aggregated. 

I'm not opposed to that if there's a demonstrated need but I have a feeling 
that here the problem is "just" the somewhat unpredictable aggregation of 
features, which should IMO be handled elsewhere.

But, as you say, let's hear from Ashish.

> 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)

Reply via email to