[
https://issues.apache.org/jira/browse/JCRVLT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003745#comment-15003745
]
angela commented on JCRVLT-61:
------------------------------
unfortunately {{Instead of telling vlt what to do, we tell it the expected
state}} will only partially solve the problem that we try to address here
afaik. imagine that one package wants to completely prevent access for
principal "A" and another package requires some specific access for that very
principal, the outcome is most probably not as you expected and the notion of
{{intended state}} is asking for wrong expections.
so, what we are looking for IMHO is a improved way to deal with conflicting or
ambiguous access control setup in the combinations:
- same-principal, same-resource, different packages
- different-principals, same-source, different packages, where the order of
entries matters
as well as with the fact we lack the ability to individually remove specific
entries.
> Allow AccessControllHandling be defined per filter root
> -------------------------------------------------------
>
> Key: JCRVLT-61
> URL: https://issues.apache.org/jira/browse/JCRVLT-61
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Reporter: Tobias Bocanegra
>
> the current packaging only allows to specify the AccessControllHandling per
> package. if one requires different behaviors for different content trees, the
> only workaround today is to create sub-packages.
> it would be nice if the ac-control handling can be defined by workspace
> filter root, similar to the iImportMode - or even tie the
> AccessControllHandling to the ImportMode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
