Diagram Governance and Editor Availability

[jdehaan]

Thanks for the comment! I plan to add the editor alike the table editor for example. The plugin would not bypass normal page rules, that means people without write rights won't be able to change things. But you are right, if the editor is too easily accessible someone might inadvertently modify things. Maybe adding an optional flag like read-only to the options will mute the editor. I think that is a good idea.

Originally posted by @jdehaan in #5 (comment)

[jdehaan]

Plan: Diagram Governance and Editor Availability

Implement the feature as a plugin UI policy, and document that real protection depends on DokuWiki ACL on both pages and media. Inline diagrams are controlled by page write rights. Media-backed diagrams are controlled by media write rights, and the embedding pages must also be protected so users cannot simply change the src= target.

Steps

1. Add a global config such as enable_graphical_editor in conf/default.php and conf/metadata.php.
2. Use that config in bpmnio.php so the plugin only emits custom section-edit wiring when the graphical editor is enabled.
3. Use the same config in editor.php and editor.php so the BPMN/DMN modeler is not injected when the feature is disabled.
4. Hide the BPMN/DMN toolbar picker in toolbar.php when the graphical editor is disabled.
5. Explicitly exclude per-tag readonly or override flags as a control feature, because anyone with page write access can change the raw tag.
6. Document the storage model in README.md and release.md:
   Inline diagrams inherit page ACL.
   src="..." diagrams inherit media ACL for file replacement, and page ACL for changing the reference.
7. Add a governance recommendation for controlled processes:
   Store canonical BPMN/DMN files in protected media namespaces.
   Restrict upload/overwrite rights in those media namespaces to designated groups.
   Also restrict write access on pages or namespaces that contain the embedding tags.
8. Add examples showing safe and unsafe permission setups so the implications are obvious.
9. Test only the plugin-side behavior in syntax_plugin_bpmnio_bpmnio.test.php, action_plugin_bpmnio_editor.test.php, and action_plugin_bpmnio_toolbar.test.php. Do not imply the plugin enforces ACL.

Why the easy alternatives are bogus

• A tag-level readonly or override attribute is bogus because a user with page write access can remove or change it in the raw wiki source before saving.
• Hiding the “Edit diagram” button is bogus as protection because it only removes the graphical editor path; the normal page editor still exposes the BPMN/DMN XML.
• Hiding the toolbar picker is bogus as protection because it only removes a shortcut; users can still type or paste the <bpmnio> tag manually.
• Protecting only the media file is bogus if the embedding page stays writable, because users can still change the src= attribute to point somewhere else.
• Protecting only the page is bogus if the media namespace stays writable, because users who can replace the referenced file can still change the effective process definition.

That is the sound concept: the plugin may control authoring affordances, but actual process governance requires aligned page ACL and media ACL.