Correct Dropdown rendering on undefined zebee:input#source

[smbea]

Related to camunda/camunda-modeler#3327, camunda/camunda-modeler#3327 (comment)

[nikku]

Great stuff. With this we're now consistent across the board, which is 🏆.

Just two minor remarks (we can ignore these and await user feedback).

[smbea]

If I understood correctly, it was an easy fix by adding isDefined there

[nikku]

I did a roundtrip test with the newly added undefined-input-binding.json template.

Result:

• Initial binding works fine (fixed in this PR)
• Removing values leads to left-overs though where the expected behavior would be to remove the bindings from XML (similar to initial creation)

However that implies we actually know what we're doing: What exactly are the semantics of input and output bindings?

Let's hold this for a moment though as I try to clarify the direction that we want to head to with Zeebe input bindings, camunda/camunda#11163.

---

    <bpmn:serviceTask id="Activity_1m5q40l" zeebe:modelerTemplate="undefined-input-binding">
      <bpmn:extensionElements>
        <zeebe:ioMapping>
          <zeebe:input source="set-2" target="ignore" />
          <zeebe:input target="test" />
          <zeebe:output source="test" />
        </zeebe:ioMapping>
        <zeebe:taskHeaders />
        <zeebe:properties>
          <zeebe:property name="test" value="" />
        </zeebe:properties>
        <zeebe:taskDefinition />
      </bpmn:extensionElements>
    </bpmn:serviceTask>

[nikku]

@smbea Let's proceed regarding the discovery in #824 (review):

Removing values leads to left-overs though where the expected behavior would be to remove the bindings from XML (similar to initial creation).

Let's update this PR and ensure on removal the whole input / property / ... is being removed, not only the value. This way we are consistent across create + apply + removal.

Properly handling task input in a no-magic fashion (camunda/camunda#11163) on the engine side is likely not built upon "empty" inputs (<zeebe:input target="test" />).

[smbea]

@nikku could you let me know how you reached those leftovers scenario? Was changing between templates? I wasn't able to reproduce it yet

[nikku]

Related bug, found through #824 (review) and hopefully properly reproducible (against this branch): #830.

[nikku]

As indicated here #830 is a won't fix / not a bug, as I missed optional completely when reproducing this issue:

• 🅰️ Element template properties with binding zeebe:input, zeebe:property and zeebe:output may be marked as optional. In that case, if they are falsy (empty string) then they must not be serialized into the XML. If they are not marked as optional they must be serialized into the XML as empty properties.
• 🅱️ Optional is not supported for zeebe:taskHeader (why?) and zeebe:taskDefinition:type (makes sense?)

To validate 🅰️ this I did the following:

• Add dedicated templates for the no variables case (with or without optional) ✔️
• Validate it works as intended using a test diagram => Optional removes empty properties, while mandatory keeps (even if properties are broken / diagram may not deploy) ✔️

[nikku]

Additional findings of the integration test:

• Optional on dropdowns is not supported; I#d assume unbind (reset to empty) to be possible, when it is not (non critical): Cannot clear Dropdown value on optional field #834
• When copying conditional properties (the Dropdown use case this PR targets) then the properties are not properly copied over (non critical; not a regression): Conditional element template property (Dropdown) lost on paste bpmn-js-element-templates#48
• We leave empty extension elements in the XML (non critical)

[nikku]

This one is also a won't fix, as it does break the optional contract.

Actual fix for the (visual) glitch reported via camunda/camunda-modeler#3327 is bpmn-io/properties-panel#203.

TLDR: We did not properly convert undefined values (i.e. input being non-existent or missing source to an empty string, not setting the select value, causing the browser default behavior to render the first select option.

[nikku]

Updated this PR to contain the properties panel patch bump (cd1b51e) + test improvements only.