[
https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232785#comment-17232785
]
Bertrand Delacretaz commented on SLING-9857:
--------------------------------------------
I also prefer an option that's visible in repoinit statements.
Ignoring things that already exist is a common behavior in repoinit so I think
that should remain the default.
bq. ...the create user/group/service user statements needed to be expanded to
allow for more fine-grained setup...
Seems to be the way to go then, but are there more than two cases?
My understanding is that if the thing being created already exists we have two
options:
* a) By default, as is the case now, ignore the supplied path statement and log
at INFO level
* b) If a specific option is set, move the existing thing to the new path and
log at INFO level
If those are indeed the only useful cases I suggest the following syntax:
{code}
create X the_name_of_X with forced path system/my-feature
{code}
Where X can be user, group, service user and the optional "forced" meaning
"move the existing object if any".
Existing scripts can then be adapted by replacing "with path" by "with forced
path".
Would that work?
Note that if there are several such statements in the overall repoinit script
being executed, the affected objects might move back and forth during the
script's execution.
> 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)
