Angela Schreiber created SLING-8757:
---------------------------------------
Summary: 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
[~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)
