Angela Schreiber created SLING-9857: ---------------------------------------
Summary: 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 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 be 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 and whether or not additional flexibility is desirable/needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)