[ https://issues.apache.org/jira/browse/SLING-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041097#comment-17041097 ]
Bertrand Delacretaz commented on SLING-8757: -------------------------------------------- I have merged the SLING-9091 PR. Please confirm that the changes to both modules match your expectations and so we can start a release for both of them. > 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 > Assignee: Bertrand Delacretaz > Priority: Major > Fix For: Repoinit JCR 1.1.18, Repoinit Parser 1.4.0 > > > [~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)