[ https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269348#comment-17269348 ]
Bertrand Delacretaz commented on SLING-9857: -------------------------------------------- I'm quite busy these days but I'll find some time to implement the suggested {{with forced path}} repoinit language option in the next few days, and hopefully someone can take it from there. > Intermediate path is ignored if user/group already exists > --------------------------------------------------------- > > Key: SLING-9857 > URL: https://issues.apache.org/jira/browse/SLING-9857 > Project: Sling > Issue Type: Improvement > Components: Repoinit > Reporter: Angela Schreiber > Priority: Major > > Sling repoinit allows to create users/groups/service users with an optional > intermediate path (absolute or relative): > {code} > create service user my-feature-service with path system/my-feature > create user my-feature-user with path /home/users/my-feature > create group my-feature-group with path my-feature > {code} > however, in case the user/group/service user already exists the intermediate > path will be ignored. > imo, there should be a way to make sure the intermediate path is respected > upon execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}} > operations. > for example: > h4. always verify and adjust path if needed > in {{UserVisitor}}: if a group/user/service user already exists and the > create-operation includes a path (i.e. {{getPath()}} doesn't return > {{null}}), verify that {{Authorizable.getPath()}} is a descendant of that > path. If that's not the case move the corresponding node by either deleting > and recreating the user/group/service user or by actually moving. > h4. global configuration option > expand the repoinit such that handling of intermediate path can be configured > for all statements. for example add a configuration option to > {{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the > verification and potentially move, if the configuration option mandates it. > the configuration could either be a simple boolean flag for this particular > case or be more sophisticated like e.g. > {{http://jackrabbit.apache.org/filevault/importmode.html}}. > h4. expand repo-init statements > if enforcing intermediate paths should not be dealt on a global level but on > a case by case basis, the create user/group/service user statements needed to > be expanded to allow for more fine-grained setup. as with the previous > option it could be a simple flag or follow the example of > {{Jackrabbit-fvault}}, which defines a variety of import modes (see > http://jackrabbit.apache.org/filevault/importmode.html). > h4. on a general note: > i see the benefit of the fine-grain import-modes (and ac-handling flags on > top of that, > http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling)) > in jackrabbit-fvault. however, in a repository setup with many features, it > becomes increasingly difficult to manage and my personal preference would > rather be to keep it simple. > note though SLING-6423: the fvault ac-handling flags already found their way > into the parser (implementation still missing though). so, maybe this issue > here in combination with SLING-6423 could be used to make a conscious > decision about the future development of repo-init beyond this improvement > and whether or not additional flexibility is desirable/needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)