Support Boolean conditions in templates

Is your feature request related to a problem? Please describe

When I want to create an element template that has conditional rendering, I want to use a Checkbox to toggle the rendering.

This is useful when multiple Values are either required or empty:

Currently, zeebe:properties do not support Boolean values. Using a normal property causes an import warning, because the engine does not support my arbitrary bpmn property.

Describe the solution you’d like

zeebe:properties support boolean values

Describe alternatives you’ve considered

Use a drop-down (yes/no) instead of a Checkbox and compare against this value

Additional context

https://camunda.slack.com/archives/GP70M0J6M/p1663658474448209

[marstamm]

I vote for supporting Boolean bindings in our bindings. Binding a String value is not intuitive for a Checkbox.

I think having a descriptive ID + Boolean value gives the user a familiar experience when it comes to optional templates.

If we go the boolean route we’d need to properly represent the boolean across all bindings (i.e. serialize it as = true input and output mappings.

I’m not to familiar with zeebe:properties inner workings, but AFAIK they are not processed by the engine and are meant as temporary values for conditionals only. We could support Boolean values for zeebe:properties but not input/output mappings, where Boolean values don’t make as much sense.

[nikku]

I’m wondering what the most elegant way to support above case is: Support boolean in our bindings or make checkbox bind to string (or feel boolean expression), too.

Checkbox is a binary (on or off) state, so if the checkbox is enabled, bind the designated (string) value to it could be a thing.

Non property bindings

{ 
  ...
  "properties": [ {
    "id": "sendMail",
    "label": "Send email?"
    "type": "Checkbox"
    "binding": {
      "type": "zeebe:input",
      "name": "fileName"
    },

    // bind an explicit string value _IF_ checkbox is checked
    "value": "some string value",

    // bind to a truthy expression
    "value": "= true",
    
    // need this to determine initial checked state
    "defaultChecked": true
  } ]
}

optional does not make sense for Checkbox. It is implicit (always optional).

value must be mandatory for every but the property binding (kept optional for property to not break existing templates ⬇️).

property bindings

value is optional for property binding (if not taken we assume property is boolean property and serialize as true if checked).

{ 
  ...
  "properties": [ {
    "label": "Executable?"
    "type": "Checkbox"
    "binding": {
      "type": "property",
      "name": "isExecutable"
    },

    // value, if not specified defaults to "true" or "false" for "property" bindings
    // assumption is that it is defined as Boolean in BPMN schema (cf. Process#isExecutable)
    // we regard this as LEGACY behavior. You are always better of to explicitly 
    // model the checked state, i.e. see `value=true` for BPMN boolean model bindings.
    
    // if value is specified then we bind it initially, based on the `defaultChecked` attribute
    "value": 5,
    "value": "= someFeelExpression",
    
    // need this to determine initial checked state, defaults to false
    "defaultChecked": true
  } ]
}

Establising bindings during template application and upgrading

If we take this route we need to have a defaultChecked=true|false attribute that we consult during initial template application and upgrading.

Considering upgrading between templates, we’d always need to make sure that the binding value is a valid declared value (value or nothing). At the same time, during upgrade, we preserve the (visual) checked state.

### Example: isExecutable Checkbox binding

* Set in BPMN 2.0 XML => checkbox is checked
* Upgrade makes defaultChecked=false
* Stays checked ("true" is a valid value)

* Not set in BPMN 2.0 XML => checkbox is not checked
* Upgrade makes defaultChecked=true
* Stays unchecked ("nothing" is a valid value)


### Example: Binary input binding <zeebe:property key="FOO" value="= true" />

* Set in BPMN 2.0 XML => checkbox is checked
* Upgrade makes defaultChecked=false
* Stays checked (valid binding)

* Not set in BPMN 2.0 XML => checkbox is unchecked
* Upgrade makes defaultChecked=true
* Stays unchecked ("nothing" is a valid value)

* Set in BPMN 2.0 XML =>checkbox checked
* Upgrade changes binding value (`= true` to `= if true then true`)
* IF same property binding exists:
   * Keeps visible checked state (but establishes new binding value)
* IF same property does not exist
   * override if value (`= if true then true`) does not match with existing value
   * otherwise, keep existing value
   
* Set in BPMN 2.0 XML, no template set
* Apply new template, establishing `= if true then true`
* override if value is does not match valid binding (none or `= if true then true`)
* otherwise, keep existing value

---

If we go the boolean route we’d need to properly represent the boolean across all bindings (i.e. serialize it as = true input and output mappings.