Ensure interoperability with connectors extension

[nikku]

What should we do?

Ensure the newly implemented replace menu plays nicely with the connectors extension.

• Integrate connectors extension for testing (Integrate connectors extension #212)
• Fix identified bugs
  • We double register "replace back to plain element" (Ensure interoperability with connectors extension #211 (comment), Improve interoperability with connectors extension #213)
  • Mouting replace menu fails on sub-process (Ensure interoperability with connectors extension #211 (comment), Improve interoperability with connectors extension #213)
  • Key replace menu entries by ID (adhere to replace menu conventions) bpmn-io/bpmn-js-connectors-extension#55
  • Fix TypeUtil#isDifferentType type util bpmn-io/bpmn-js#1787

Why should we do it?

We are able to transition smoothly between both versions.

---

Related to #214.

[nikku]

CC @smbea. I'm currently looking into this.

[nikku]

We double register "replace back to plain element":

[nikku]

Mouting replace menu fails on sub-process:

[smbea]

We double register "replace back to plain element":

This can be prevented by checking if it's there first

Mouting replace menu fails on sub-process:

That one I have to check, not sure what is going on

[nikku]

Mouting replace menu fails on sub-process:

That one I have to check, not sure what is going on

I can provide a fix for this one @smbea

[nikku]

We double register "replace back to plain element":

This can be prevented by checking if it's there first

Two options to fix this:

• Check (in either place) if the thing already exists
• Ensure both use the same keys (currently replace-with-service-task -> camunda-bpmn-js, replace-unlink-element-template -> connectors extension).

If we decide to use the same entry ID we should settle down on one of them; if we want to distinguish replace-with-service-task from the unlink option (i.e. during tracking) I'd say, let's call this thing replace-unlink-element-template.

[smbea]

My initial thought was that although for us it's replace-unlink-element-template, to the user it means replace-with-service-task. But since it's not really something shown in the UI and the first option might be more beneficial to us during tracking, maybe let's go with replace-unlink-element-template.

[nikku]

Entries to apply element template appear twice due to different IDs:

Same root cause + resolution like #211 (comment) I think @smbea.

[smbea]

The fix for the first situation (unlink template) would be this: https://github.com/camunda/camunda-bpmn-js/compare/211-change-unlink-template-action-name

But actually, changing the id here doesn't fix the issue for the last case mentioned because the entries still differ (the entries fed from here have groups and the others have categories. And those aren't translated since they aren't fed through here, they are fed through the connectors extension @nikku

[nikku]

But actually, changing the id here doesn't fix the issue for the last case mentioned because the entries still differ

The entries have different IDs as well, hence multiple ones are attached, I think?

[smbea]

They do. But what I'm saying is: changing the ids to match with the ones given in the connectors extension doesn't fix the issue, because of how they are added https://github.com/bpmn-io/bpmn-js-connectors-extension/blob/08816c046cc42adc470052826f56bdd4ca9bc52f/src/replace-menu/ReplaceMenu.js#L98. Since the entries still differ (category vs group for example), they are added on top.

I added a WIP commit here if you want to test it out.

[smbea]

As agreed, let's not push this for Modeler 5.6.0 since there are still some loose ends we need to align regarding the usage with the connectors extension

[nikku]

#211 (comment)

@smbea this is fixed via bpmn-io/bpmn-js-connectors-extension#55. There is no good reason why the connectors extension shall not adhere to the existing replace menu contract (keying element uniquely, by ID).