Camunda-modeler: BPMN Plugins don't work with Camunda Cloud BPMN models

[falko]

__Describe the Bug__

Camunda Modeler plugins that extend the BPMN modeling experience don't work with BPMN models that use the execution platform Camunda Cloud.

__Steps to Reproduce__

1. Install BPMN plugins, e.g. Generate Technical IDs or the Layering Plugin
2. Create a new Camunda Cloud BPMN model
3. The plugins don't show on the BPMN canvas.

__Expected Behavior__

The plugins work as they do in Zeebe Modeler. I don't see a reason to force all plugin authors to change their plugins, in case that was the plan. It's still BPMN. It's just another set of extension attributes & elements in the property panel. Most BPMN plugins don't even touch these. This is a blocker for switching from Zeebe Modeler to Camunda Modeler 4.8+ for customers using BPMN plugins.

__Environment__

• OS: Ubuntu 20.04.2 LTS
• Camunda Modeler Version: 4.9-nightly.20210520
• Execution Platform: Camunda Cloud
• Installed plug-ins: [Cloud Sync, [Generate Technical IDs](https://github.com/camunda-consulting/code/tree/master/snippets/camunda-modeler-plugins/bpmn-js-plugin-rename-technical-ids), [Layering](https://forum.camunda.org/t/layers-plugin/27511)]

[pinussilvestrus]

It was intended to keep the existing plugins out of the Cloud Tab for now. Bringing support for these diagrams means we have another layer for which plugins can be created. Before, bpmn-js plugins were simply intended to be registered for any kind of BPMN diagrams, no matter in which context (Platform our Cloud). The plugin point simply does not offer this variation.

However, there were already plugins created which (hiddenly) forces the Camunda namespace to be available, for example this one. Plugins were always a first-hand feature of the Camunda Modeler.

If we simply enable the bpmn-js plugin point for Cloud diagrams as well, negative side effects could happen (mixing namespaces) - at least this was the assumption why we disable bpmn-js plugins for Cloud diagrams.

You could argue: well, if you want to install a plugin, you know what you're doing and that the plugin won't properly work for another Engine. Then we could simply enable it back again.

I think what we came up with is to avoid these mixing scenarios and find a better way to actively indicating plugins for an engine OR to indicate them as generic - instead of having the single plugin point for bpmn-js.

[MaxTru]

Thanks Niklas, that helps.

I propose that we have a dedicated activity to evaluate and decide how we cope with this as part of our OKRs. This will allow us to deliver a stable solution for Camunda Modeler users.

[ingorichtsmeier]

Adding a camunda: element via modeler plugin (even accidentially) should not hurt the cloud process, if it adds the camunda namescape automatically.

Same vice versa.

[falko]

I agree with Ingo that Camunda-Platform-specific plugins can do no harm because many extension namespaces can be mixed in BPMN. Therefore we shouldn't punish authors and users of plugins that just work on standard BPMN elements and attributes. I would assume that is the majority of BPMN plugins.

How about a warning in the log if Camunda Cloud is the execution platform and a camunda:* extension element or attribute is created through the bpmn.js API by a plugin?

[nikku]

We'll consider this one as a future improvement.

It is clear that we'd like to have plug-ins for Camunda Cloud, too.