Camunda-modeler: Applied Element Template is not unlinked, when changing to not supported element type

Created on 6 Oct 2020 · 5Comments · Source: camunda/camunda-modeler

__Describe the Enhancement__

When applying an task-specific element template to a task of a specific type (e.g., ServiceTask) and then changing the type of the respective task (e.g., to UserTask), the element template is still present. This is IMO an inconsistent state, since the element template configuration would not allow that template to be applied to a task other than ServiceTask.

__Steps to Reproduce__

Setup the following example element template

{
    "name": "Mail Task",
    "id": "com.camunda.example.MailTask",
    "appliesTo": [
      "bpmn:ServiceTask"
    ],
    "properties": [
      {
        "label": "Implementation Type",
        "type": "String",
        "value": "com.mycompany.MailTaskImpl",
        "editable": false,
        "binding": {
          "type": "property",
          "name": "camunda:class"
        }
      },
      {
        "label": "Sender",
        "type": "String",
        "binding": {
          "type": "camunda:inputParameter",
          "name": "sender"
        },
        "constraints": {
          "notEmpty": true,
          "pattern": {
            "value": "^[A-z0-9._%+-]+@[A-z0-9.-]+\\.[A-z]{2,}$",
            "message": "Must be a valid email."
          }
        }
      },
      {
        "label": "Receivers",
        "type": "String",
        "binding": {
          "type": "camunda:inputParameter",
          "name": "receivers"
        },
        "constraints": {
          "notEmpty": true
        }
      },
      {
        "label": "Template",
        "description": "By the way, you can use <a href=\"https://freemarker.apache.org/\">freemarker templates</a> here",
        "value": "Hello ${firstName}!",
        "type": "Text",
        "binding": {
          "type": "camunda:inputParameter",
          "name": "messageBody",
          "scriptFormat": "freemarker"
        },
        "constraints": {
          "notEmpty": true
        }
      },
      {
        "label": "Result Status",
        "description": "The process variable to which to assign the send result to",
        "type": "String",
        "value": "mailSendResult",
        "binding": {
          "type": "camunda:outputParameter",
          "source": "${ resultStatus }"
        }
      },
      {
        "label": "Send Async?",
        "type": "Boolean",
        "value": true,
        "binding": {
          "type": "property",
          "name": "camunda:asyncBefore"
        }
      }
    ]
  }

Apply the template to a serviceTask
Change the task type to userTask
=> The element template is still applied

__Expected Behavior__

The element template shall be unlinked, if not supporting the respective new task type.

__Why__

If we don't have this, the user would get to an inconsistent state of the diagram (according to the element template configuration)

__Environment__

OS: Arch Linux Manjaro
Camunda Modeler Version: develop branch + develop branch bpmn-js-properties-panel on 6th October

element templates enhancement

Source

MaxTru

Most helpful comment

The solution I've discussed with @azeghers is:

when the template cannot be found it will be unlinked
when the template can be found it will be unlinked if it can't be applied to the new element

CodeSandbox example: https://codesandbox.io/s/restricting-camundamodelertemplate-nyrtp?file=/src/index.js

philippfromme on 30 Oct 2020

👍3

All 5 comments

Maybe we could listen for shape.replace and check whether the template is still applicable. I think we already do similar for other events in some command handler for the element templates.

pinussilvestrus on 28 Oct 2020

and check whether the template is still applicable.

I think we cannot check this in all cases since the template might be not available (e.g., file deleted).
Therefore we could:
A) only check this, if the template is still present
B) simply always unlink once you use the wrench

I would opt for B.

MaxTru on 29 Oct 2020