neos / neos-development-collection

The unified repository containing the Neos core packages, used for Neos development.
https://www.neos.io/
GNU General Public License v3.0
260 stars 220 forks source link

BUG: CopyNodesRecursively vs Content Dimensions #5054

Open nezaniel opened 1 month ago

nezaniel commented 1 month ago

Is there an existing issue for this?

Current Behavior

When we copy a node, it is not possible to copy a variant of said node to the same location without losing the connection

Expected Behavior

We need to find a way to make interdimensional node copy possible, similar to MoveNode

Steps To Reproduce

Create a node Vary that node to a different DSP Copy the node in the source DSP Copy the node in the varied DSP See how the aggregateIds differ and the copied variants are detached

Environment

- Flow: 9.0.x-dev
- Neos: 9.0.x-dev
- PHP: 8.2

Anything else?

No response

nezaniel commented 1 month ago

To elaborate on this: Given the following variation and content graph:

CopyNodes

When we copy Node "mc-nodeface" in origin DSP {"language": "ltz"} to a new parent "nodington-iii" in the same DSP, the following happens:

CopyNodes-Copy1

The first weird thing is, that "nodimus-copied" is now varied to ltz, where its original did only exist as a virtual variant. That's acceptable though imho.

What troubles me more is what happens if I decide to not only copy the node, but all its variants (which kind of makes sense, even by default). Since I cannot define a DSP set which to copy, I have to do this by hand with a second command:

CopyNodes-Copy2

By default, the nodes again get new - and thus differing - aggregateIds, although they were copied from the same original. We copied one node aggregate into two and there is no way to remediate this (except, of course, with vary, copy&paste content, delete). And if we tried again with the same NodeAggregateId mapping, node creation would fail due to the aggregates already existing.

What could we do instead? Either we also copy all variants by default or we need the ability to copy via variation instead of creation. In the latter case, we'd need to store the NodeAggregateId mapping $somewhere and on the next copy reevaluate it and perform variation on the target Ids instead of creation.

Questions so far?