Support boolean and number `value` for `feel: static` property

[barmac]

Is your feature request related to a problem? Please describe.

Before bug described in #192 (comment) was introduced, user had to set value field to =true in both template property and condition to achieve correct values.

Describe the solution you'd like

Allow to use boolean and number values in the JSON for feel: static properties:

{
    "id" : "input.grounding",
    "label" : "Grounding",
    "description" : "Customize grounding by Vertex AI Search.",
    "optional" : false,
    "value" : false,
    "feel" : "static",
    "group" : "input",
    "binding" : {
      "name" : "input.grounding",
      "type" : "zeebe:input"
    },
    "type" : "Boolean"
  }, {
    "id" : "input.dataStorePath",
    "label" : "Vertex AI data store path",
    "group" : "input",
    "binding" : {
      "name" : "input.dataStorePath",
      "type" : "zeebe:input"
    },
    "condition" : {
      "property" : "input.grounding",
      "equals" : true,
      "type" : "simple"
    },
    "type" : "String"
  }

This way I don't need to know that feel: static results in an expression being written to the property.

Describe alternatives you've considered

Leave it as is, but warn about improper type.

Additional context

Related to #192

[nikku]

From what I understood in #192 this has never worked (before) for feel: static. So what this request suggests is that we do the hard work to make it simple as the user creates and element template:

• They can define true for value of a feel: static field, and we will "fix that" so it ends up as = true in the BPMN model.

As you mentioned we'd need to apply that logic to any entry that supports feel: static (number and boolean entries at the moment).

The alternative is that we invest into guidance and/or validation to fix this issue, and better indicate that feel: static entries must have expressions as default values. We currently don't indicate that. The benefit of what is proposed here is that users can continue to model data in JSON, the domain they define the element template in, and we could validate value. For example, a boolean field would need to have a boolean (or a = true/false expression) in the value to be valid.

[sbuettner]

Hey @barmac, did you groom this ticket? Curious about whether its planned or not?

[barmac]

Hi, it's planned but not in the current iteration. We will get to it though.

[jarekdanielak]

We've recently introduced a rule that marks the value field as deprecated if it doesn't start with the = sign for feel: required properties, cf. camunda/element-templates-json-schema#196

I understand the argument of doing the hard work for the user, but we should keep it consistent:

• If a value has to be FEEL, it must be a string starting with =. Anything else is invalid.

OR

• value can be anything. Element templates will figure out if it should be FEEL (for required and static) and parse it.

[barmac]

What do you think we should do?

[jarekdanielak]

I'd opt for ensuring every FEEL value starts with =.

[barmac]

How does it relate to our design principles? If I understand your proposal correctly, we'd need to disallow the templates like the one in the top comment, and close the feature request despite users' needs.

[jarekdanielak]

In the light of doing the hard work to make it simple, we should allow both.

Then we should revisit our strategy for feel: required and handle both value and =value there, without the deprecation warning.

[jarekdanielak]

Number conditions currently work as follows:

• Value 5 matches condition equals 5.
• Value "=5" matches condition equals 5.
• Value 5 does not match a condition equals "=5".
• Value "=5" does not match a condition equals "=5".

So it seems we currently actually support numeric values, but do not support all combinations of numeric and FEEL string? 🤔

@barmac To make both the behavior for number and boolean consistent*, I assume we should support all of the above combinations.

*consistent after #192 is fixed, cause now Boolean type is just broken.