[
https://issues.apache.org/jira/browse/SLING-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16946751#comment-16946751
]
Angela Schreiber commented on SLING-8757:
-----------------------------------------
[~bdelacretaz], unfortunately i am currently busy with some other critical
issues and i don't have time to look into this right now.... if it's urgent a
sling committer should take care... which would also be more effective because
i usually have to run around a bit looking for someone that has time to commit
my patches.
just a comment regarding the suggested syntax: it is not sufficient to just add
this to "set ACL". you also have to adjust "set principal ACL" and maybe also
"set ACL for alice, bob"... since AEM mainly needs to setup service user
permissions the 'set principal ACL' will essentially be the main use case for
that in the future. that's what i meant with adding too much additional
complexity and that's the reason why i suggested a different option.
> Add option to set/edit access control policies at user homes
> ------------------------------------------------------------
>
> Key: SLING-8757
> URL: https://issues.apache.org/jira/browse/SLING-8757
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Angela Schreiber
> Priority: Major
>
> [~rombert], while looking into moving all service user creation and
> permission setup from content packages to repo init, i noticed that there is
> one special case that doesn't seem to be covered by repo init but possible
> with Jackrabbit content packages: creating/editing access control policies at
> a user home. the path of those is an implementation detail and cannot be
> 'guessed'.
> based on my previous work on the repo-init grammar, i could envision the
> following main options to include this functionality.
> # explicitly extend the 'path-token' which is currently defined to be
> {{(PATH_STRING> | t = <PATH_REPOSITORY>)}} to something like {{(PATH_STRING>
> | t = <PATH_REPOSITORY> | <USER_ID>)}}.
> # similar to the first one: but don't touch the grammar just extend the
> jcr-implementation: if 'path' is a relative path and is not _repository_,
> treat it as userId and try to obtain a path from the corresponding user
> object.
> # completely separate it from the 'pathList' and don't allow a combination of
> absolute paths, repository-marker and userIds, explicitly include the notion
> that the edited policy is not bound to a regular path but to a user home....
> instead of {{on /abspath, repository}} it then would e.g. say {{on user id1,
> id2}}
> without having looked into it in great detail and given the fact that there
> are already so many different ways to edit access control content with
> repo-init, the first option would feel the most natural to me.
> wdyt? i could try to come up with a patch/tests/docu, but i would love to
> avoid investing a lot of time and then have to throw it away or redo it all
> over again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
