[
https://issues.apache.org/jira/browse/JCRVLT-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687831#comment-17687831
]
Julian Reschke commented on JCRVLT-685:
---------------------------------------
Note: the behavior not to restore properties for ImportMode == REPLACE was
introduced in
https://github.com/apache/jackrabbit-filevault/pull/159/commits/847ac6079cde864f8f51ec6b8435d0f07449de6a#diff-09802c15c5245b46b94dbbf302adfeef658cfb273119b35cfec69e40824464f3R190
(JCRVLT-551).
Removing the "if" statement does not cause any test failures.
> ImportMode REPLACE vs IdConflictPolicy LEGACY vs stashing
> ---------------------------------------------------------
>
> Key: JCRVLT-685
> URL: https://issues.apache.org/jira/browse/JCRVLT-685
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
> Affects Versions: 3.5.4
> Reporter: Julian Reschke
> Priority: Major
>
> Consider this case:
> - existing node "/tmp/x" in repo with UUID x1 and mixin type xm that requires
> a child node "/tmp/x/child"
> - package import with IdConflictPolicy.LEGACY and ImportMode REPLACE
> (default). Packacge contains /tmp/x" with UUID x2 (!= x1) and does not have
> the mixin type xm, nor the child node required by it
> Import detects UUID present in package and on node to be updated, decided to
> stash it. New node is created, child nodes are moved back from stashed node,
> but properties are not (due to ImportMode REPLACE), thus the mixin type is
> not re-added. Import fails.
> Either we should restore the mixin type, or we should not restore the child
> that is only allowed by that mixin type.
> (This is a change in behavior introduced by JCRVLT-551)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
