Move a nested Paragraph across fields and nesting

+1. Would be be a really nice feature to have. If implementing this by drag n drop was too difficult, it would still be a nice step forward to have an action "Move to another container" available in the actions dropbutton, which triggered a dialog asking what the new parent for this paragraph should be.

Yeah that's a nice idea.
However, this leads us to a problem with our direction described in previous architectural discussions:
With this issue #2641824: Maintain composite relationship the parent relationship is maintained by entity reference revisions.
And with this change of architecture, we consider the parent relationship of a paragraph as immutable.
It's a bit similar to entities that can not change their bundle once saved, because this is not offered by our APIs.

Nesting will create a very complex situation combined with a change of the parent relationship.
If we ever want to support this, we would need a special pluggable event that is triggered when changing the parent.
Before we can support this ever, we need to think in more detail about the consequences.

I need to postpone this on the composite relationship issue.

Might it be possible to use a "Copy then Delete original" pattern behind the scenes, if the parent was immutable?

#2641824: Maintain composite relationship is almost resolved, so unpostponing this.

@Miro: can you suggest the right architectural direction to go with this?

Can't help currently. Our focus for now is clearly fix the composite relationship first. The composite issue is without progress for way too long.

We will need to find time to discuss this to figure out what fits best.
Cloning the item with deleting the previous one would be the most unsatisfying approach, but dunno yet what is possible...

So discussed this.

A paragraph entity can be without a parent. It is during creation persisted like that and receives an update to attach it to the parent.
This means technically we can also support moving / switching it.

That said, we realised, the composite paragraph should possibly also store the field name to allow real field access check and not only entity access check.

To support dragging like requested, it means we need to break out of the field and this needs a rewrite of the dragging code.
Note also this requires us to attach data attributes to save the paragraph type and attach the supported paragraph types per field to validate the drag and drop action. This is needed because not all paragraph (entity reference revision) fields can contain all paragraph types.

I'm finally concerned about the complexity this adds and it will add many special conditions and if spaghetti. Let's first complete the current work and cleanup the duplicate code and break things into smalller logical pieces, before adding it.

Makes sense to refactor first. The UI issues for this feature will also be very tricky. I haven't been able to think of a simple alternative to dragging, and dragging gets really hard if paragraphs are open.

Therefore this may have a soft dependency on #2650306: Always offer Collapse/Preview/Edit.

I don't think that this collapse button is so much nice.

Instead i think i would extend the JS that it autocollapses things then in drag mode.
And with collapsing i mean every level should still stay available including nested ones, but every paragraph item is reduced to a narrow row with a label that provides orientation.

:-)

And linking the alternative UI issue, since we are starting to break default UI limits to figure out how far we need to go with alterations or when we will stop and offer it as a separate optional module.

I've been looking into this and the js goes beyond my js skills. I've found a nice example for the table in http://wadmiraal.github.io/jquery-tabledrag/ but it is sightly out of our approach since it adds a parent field to the field. Not sure how to continue with this, maybe someone else with better knowledge about js can work on this. :)

This is being worked on in #2825575: Introduce a Drag & Drop Mode

Moving elements across hierarchy levels works when using the special "..." > "DRAG-AND-DROP" mode. The standard drag and drop behaviour only allows moving elements on the same level inside the same parent element.

Moving elements across hierarchy levels works when using the special "..." > "DRAG-AND-DROP" mode. The standard drag and drop behaviour only allows moving elements on the same level inside the same parent element.

@cweiske Where is that special mode you are referring to? What form options need to be set? ATM I have the form element set as 'Paragraphs (Stable)' and the 3 dots do not contain the 'drag-and-drop' as option.

I'm using the thunder_admin theme - no idea if other themes have this. Screenshots at http://p.cweiske.de/819

Also see https://www.drupal.org/docs/contributed-modules/paragraphs/hints

Current paragraphs module does not seem to support it and I would be surprised if the theme had anything to do with it. Thanks anyway.

The admin theme absolutely is related to this, this is a long-standing issue with claro for example: #3099026: Claro's preprocessing of field multiple value form's table header cell removes potential changes by others

@Berdir Thanks, that's helpful. I previously tested both with claro and gin to no avail (doh, gin is based on claro). It works with this patch.