Add element templates to replace menu

[smbea]

What should we do?

Add element templates to replace menu options

Why should we do it?

In the context of support replace anything, see bpmn-io/bpmn-js#1627

[smbea]

My current implementation for this consists in adding a replace menu provider that feeds element templates as menu entries (like "ElementTemplatesProvider").

[smbea]

WIP: https://github.com/camunda/camunda-bpmn-js/tree/204-add-replace-anything

---

The end goal of replace with templates:

In bpmn-js-connectors-extension, the replace is populated with templates which apply to the current selected element (see https://github.com/bpmn-io/bpmn-js-connectors-extension/blob/6ac379adf9b366eed0e37d9986d9762c1964f946/src/replace-menu/ReplaceMenu.js#L51).

Example: if default task is selected, only templates that have appliesTo: ["bpmn: Task"] appear.

To consider: allow replace with any templates? In the same context that we can replace a default task with a service task, does it make sense to allow replace of a default task with a service task template (replace element + apply template)?

[nikku]

@smbea A little summary of our chat (weekly) on this:

• Elements not appearing if appliesTo: [ element not in list ] is expected behavior
• For elements to appear (i.e. ServiceTask -> UserTask replacement) you have to appliesTo: [ bpmn:Task or bpmn:ServiceTask,bpmn:UserTask ]. elementType is the designated utility that allows you to define into which element type the element is changed during replace.

[smbea]

I have an initial draft for this in #207. Before getting into the nitty gritty, I would like to get some feedback on the high level structure/organisation of the feature. Does the location of the new provider added make sense? Should it be structured different?

[nikku]

@smbea I've commented on the PR.

The solution looks simple enough; let's make sure it plugs in correctly end-to-end, also including edge cases (service task backed template -> service task (unbind template)).

Also does it make sense to structure this in accordance with bpmn-js feature structure?

[smbea]

I missed that part indeed, will work on it now.

I think it makes sense to follow that structure (like ../features/replace). It's what we already do in our other tools and we already have the features dir in here.

[smbea]

I was working on allowing to replace back with plain element (service task backed template -> service task). But I am struggling to make sure the option is added back in the original position when working with the first task. This also appears as a bug on the connectors extension, example:

After applying a template to a Task, the Task replace option doesn't appear where it should be:

[nikku]

From discussions with @marstamm when we fixed that issue I remember that we did the least effort thing to build it.

I cannot reproduce #204 (comment) on the connectors extension, unfortunately.

---

What the extension implementation does is to try to insert the element in the original position, taking the next and previous elements as an anchor.

The element itself cannot be replaced, as it is filtered out at the core. We could decide to improve this in the core by making it pluggable or element template aware.

[marstamm]

[FYI]: this is the commit that changed the unlink entry position: bpmn-io/bpmn-js-connectors-extension@0ec6a11

EDIT: Nico was faster and already added the relevant code in the original comment 😄

[smbea]

It works for middle positions like Service Task. I had an issue in trying to apply a template to Task. I tried with this template:

{
  "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json",
  "name": "AppliesToTask",
  "id": "com.camunda.example.AwesomeTask",
  "appliesTo": [
    "bpmn:Task"
  ],
  "properties": [
    {
      "label": "Are you awesome?",
      "type": "Boolean",
      "value": true,
      "binding": {
        "type": "property",
        "name": "customProperty"
      }
    }
  ]
}

[nikku]

@smbea In this case the implementation shall hook the task up in front of the next element in the line. It may be broken, then we need to fix it.

My suggestion is: Let's incorporate it, build some basic test coverage around it, and investigate + fix all bugs we find in the process.

[smbea]

I have looked into the implementation and I understand why it happens. But I was testing out edge cases and it seemed like a bug to me so I wanted to be on the same page.

Since it works for most cases, I will do that: incorporate like this and then improve on top. Thanks for the insight!