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

Bertrand Delacretaz edited comment on SLING-8757 at 2/20/20 11:40 AM:
----------------------------------------------------------------------

I have now pushed the missing commits to master at 
[https://github.com/apache/sling-org-apache-sling-repoinit-parser]

I have also added a new integration test to the jcr-repoinit module that 
validates this new {{home()}} syntax end-to-end including parsing and JCR 
operations. I think we should do that for all new repoinit features in general, 
see the [corresponding 
commit|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/9800e4f7a7aadee212c3acfdcfb34fb40634cede].

_Update_: also disabled the comma-separated lists in functions, like 
{{home(alice,bob) }}in [commit 
f6d7255|https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/f6d72556f9004fdabcd7e258c344d178b5fb4ff0]
 - I don't think that's supported downstream and easy to reactivate if we need 
them. 

 [~angela] could you confirm that this matches your expectations? We can then 
release the parser module, for jcr-repoinit it's only test changes so no need 
to release IMO.


was (Author: bdelacretaz):
I have now pushed the missing commits to master at 
https://github.com/apache/sling-org-apache-sling-repoinit-parser

I have also added a new integration test to the jcr-repoinit module that 
validates this new {{home()}} syntax end-to-end including parsing and JCR 
operations. I think we should do that for all new repoinit features in general, 
see the [corresponding 
commit|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/9800e4f7a7aadee212c3acfdcfb34fb40634cede].

 [~angela] could you confirm that this matches your expectations? We can then 
release the parser module, for jcr-repoinit it's only test changes so no need 
to release IMO.

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

Reply via email to