You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2019/01/07 15:24:00 UTC

[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name

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

Bertrand Delacretaz edited comment on SLING-8186 at 1/7/19 3:23 PM:
--------------------------------------------------------------------

I have added an integration test [1] which demonstrates that the interaction between @Delete and @MoveFrom has been like that for a long time indeed: running that test against a Sling 8 jar with {{org.apache.sling.servlets.post}} 2.3.8 (released June 2015, way before Carsten's change mentioned above) gives the same results.

I think we have an edge case that's not clearly documented, but I wouldn't be comfortable removing the "delete node if property not found" behavior as that wouldn't be backwards compatible.

We might clarify the documentation to indicate that having an @Delete parameter pointing to the target path causes a deletion like in this example - if unsure, users should refrain from using @Delete and @MoveFrom in the same request.

[~bupauli] what do you think?

[1] [https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/3da37cc963fa1367d07eb1ed2d37cb3296d6b270]


was (Author: bdelacretaz):
I have added an integration test [1] which demonstrates that the interaction between @Delete and @MoveFrom has been like that for a long time indeed: running that test against a Sling 8 jar with {{org.apache.sling.servlets.post}} 2.3.8 (released June 2015, way before Carsten's change mentioned above) gives the same results.

I think we have an edge case that's not clearly documented, but I wouldn't be comfortable removing the "delete node if property not found" behavior as that wouldn't be backwards compatible.

We might clarify the documentation to indicate the having an @Delete parameter pointing to the target path causes a deletion like in this example - if unsure, users should refrain from using @Delete and @MoveFrom in the same request.

[~bupauli] what do you think?

[1] [https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/3da37cc963fa1367d07eb1ed2d37cb3296d6b270]

> Moved node is deleted if @Delete parameter points to its name
> -------------------------------------------------------------
>
>                 Key: SLING-8186
>                 URL: https://issues.apache.org/jira/browse/SLING-8186
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Servlets Post 2.3.26
>            Reporter: Burkhard Pauli
>            Assignee: Bertrand Delacretaz
>            Priority: Major
>
> If a file is moved to a new location with the @MoveFrom parameter and the request contains the @Delete parameter at the same time, the file is dropped and never saved to the new location.
> Step to reproduce the issue:
>  # Create a node of type nt:file at the location {{/content/file}}
>  # Execute the following curl command:
>  {{curl -u admin:admin -F './test/title=Hello World' -F './test/file@MoveFrom=/content/file' -F './test@Delete=true' [http://localhost:4502/content]}}
> Observed behaviour:
>  The file is not saved at the new location at {{/content/test/file}} and it is not available anymore at the old location {{/content/file}}
> Expected:
>  The file is saved at the new location {{/content/test/file}} as long as other properties are saved when the request contains the delete operation (like the title property in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)