Open nezaniel opened 1 month ago
To elaborate on this: Given the following variation and content graph:
When we copy Node "mc-nodeface" in origin DSP {"language": "ltz"} to a new parent "nodington-iii" in the same DSP, the following happens:
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:
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?
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
Anything else?
No response