umbraco / Umbraco.Deploy.Issues

1 stars 0 forks source link

v13: Deletion dependencies and content transfer #223

Closed Frost117 closed 1 month ago

Frost117 commented 2 months ago

There are scenarios where content is deleted on a remote environment. That content is likely to have sub-nodes or dependencies which are deleted along with the parent node.

Take the following scenario. You got 1 development environment and 1 production environment.

On the production environment you have the following structure: image

The blog node gets deleted by accident and luckily we have a backup of the node in the development environment. We then transfer the blog node and all of its content and sub nodes to production.

However when viewing the content on production, we see that the sub nodes are marked as being deleted. image

Reproduction

Bug summary

It looks like when the content transfer comes it correctly sets the blog node, as not deleted, but each of the child nodes, are still set as deleted.

Republishing the content node and subnodes before transferring still yields the same result where the child nodes are marked as deleted.

Specifics

Umbraco CMS version 13.3.2 Umbraco Deploy version 13.1.0

image

image

Steps to reproduce

Create project v13 Create following structure: Parent node (Home) 2 Child Node (Blog and Contact) Under blog node, allow the use of list view for sub nodes create 2-5 sub nodes under the blog node. Content transfer site to live Delete blog node and all sub node on live. Try and transfer the blog node and all of its sub nodes and verify the issue on live

Expected result

I would have expected that if we transfer a node that was deleted along with its sub-nodes then we would see those nodes in a unpublish state and not in a deleted state.

Actual result

Transferring a non-deleted node from dev to a prod env where the node was deleted, yields the result of being publish on live but its child nodes are still marked as being deleted

ronaldbarendse commented 2 months ago

Hi Eric! Looking at the history of 'Article 3' on the Live environment, this node was not completely deleted, but still in the recycle bin, before the deployment moved it back into the content tree.

The 'Blog' node is correctly updated though, which leads me to believe that when Deploy moves this node back into the content tree, the CMS correctly updates the Trashed flag on that node. But because the children aren't explicitly moved by Deploy (the parent is unchanged), it apparently doesn't update the Trashed flag. I'll have to debug whether this is something in Deploy or the CMS though 🤔

Can you clarify whether you've transferred the 'Blog' node using 'Include descendants' and whether you see the same happening when the nodes are also deleted from the recycle bin?

Frost117 commented 2 months ago

That makes sense.

Of course Ronald, when I transferred the Blog node, I used the 'Include descendants' check.

If I empty the recycle bin on live, making sure that the 'Blog' node along with it descendants are cleared out, then when I transfer the content node 'Blog' it shows up correctly on the remote env.

ronaldbarendse commented 2 months ago

Thanks for clarifying and verifying that it only happens when the nodes are still in the recycle bin.

I've replicated it and can see that the CMS indeed isn't correctly updating the Trashed flag on the child items, but only when the child items are also processed/deployed within the same scope/operation. If you don't check 'Include all items below' when transferring 'Blog', the child items are correctly restored from the recycle bin 🙃

This seems to be because if the child items are fetched by Deploy (using the IContentService), the Trashed flag is still true (even though it is false in the database) and that is then saved again when the item is processed. This most likely is an issue within the CMS repository cache or cache refreshers, as this flag is only updated on child items by saving using the document repository (see PerformMoveContentLocked in the CMS).

Because the CMS in most cases only performs the move in a single scope, this is only surfaced in Deploy (that does multiple operations in a single scope). Although it should really be fixed in the CMS, I'll see if we can add a work-around in Deploy in the meantime 👍🏻