@fsbraun nice! I thought a bit about this and have two use cases:

1. would dragging aedit_disabled plugin outside the controlling parent still be possible, e.g. can an editor (accidentally?) destroy a parent-child complex designed by a developer so that it becomes unusable, especially as the controlling parent plugin template (probably?) counts on the existence of specific child plugins in a specific order?

2. dragging aedit_disabled plugin inside the controlling parent, e.g. changing the order of its child plugins. This might cause a similar issue, the controlling parent's template might expect the controlled children to be in a specific order?

In summary, would it make sense to also disallow direct drag & drop foredit_disabled plugins?

Of course, dragging them via a parent plugin should always be possible, as the whole complex can be dragged to another position in the placeholder, can be cut or copied and pasted elsewhere.

@macolo Draging is still fully controlled byallowed_parents andallowed_children. This means I could change the order of columns or move a column to a different row. But I should not be able to drag a column into something else than a row.

Indeed, the parent plugin cannot rely on the existence or order of child plugins. Any management code must be flexible and say recreate a missing child if needed, or might want to merge if there are several children, say, for a single slot. Disabling dragging alone would not solve this issue: There is also pasting or adding plugins.

PS: The custom component construct does ignore the order of the child plugins.

@macolo I have now implemented drag-disabling in principle (CSS and JS side). Shall we go for another plugin option that disables drag for child plugins? It would also need to disable add and paste. Something likechild_edit_disabled...

Reviewer's Guide by Sourcery

This pull request introduces the ability to disable the edit modal for plugins. This is achieved by adding an 'edit_disabled' property to the plugin class or instance. Additionally, it allows adding custom classes to the drag item in the structure board via the 'add_structureboard_classes' property.

Sequence diagram for plugin edit interaction with disabled editing

sequenceDiagram    actor User    participant UI    participant Plugin    participant Editor    User->>UI: Double clicks plugin    UI->>Plugin: Check edit_disabled status    alt edit_disabled is true        Plugin-->>UI: Editing disabled        UI-->>User: No action    else edit_disabled is false        Plugin-->>UI: Editing allowed        UI->>Editor: Open edit modal        Editor-->>User: Show edit interface    end

Class diagram showing plugin edit configuration changes

classDiagram    class Plugin {        +edit_disabled: bool        +add_structureboard_classes: string        +allow_children: bool        +disable_child_plugins: bool        +get_plugin_class()    }    class PluginInstance {        +edit_disabled: bool        +add_structureboard_classes: string    }    Plugin <|-- PluginInstance    note for Plugin "New properties added:edit_disabled andadd_structureboard_classes"    note for PluginInstance "Can override class-leveledit_disabled setting"

State diagram for plugin edit states

stateDiagram-v2    [*] --> Normal    Normal --> EditDisabled: edit_disabled=true    Normal --> Editable: edit_disabled=false    state Editable {        [*] --> Ready        Ready --> EditModal: Double click        EditModal --> Ready: Close modal    }    state EditDisabled {        [*] --> NoEdit        NoEdit --> NoEdit: Double click (no effect)    }

File-Level Changes