Support FEEL for fields' default value

[tobiasschaefer]

Problem you would like to solve

Currently, the default value of various fields (Number, Datetime, Text field, Text area, Checkbox, Radio, ...) can only be a static value. I'd like this to be a FEEL expression so that this can be dynamic, e.g. based on process variables.

Proposed solution

It would be great if the default value could be switched between a static text and a FEEL expression. This would be similar to other properties, e.g. Label, Field Description, ...

Alternatives considered

I'm not aware of an alternate solution or workaround.

Additional context

I'd like to see this for C8 - I'm not sure if this could also be applied to C7 forms.

It could look like this: (note I added the blue "fx"):

And when "fx" is clicked it looks like all other fields which allow FEEL expressions:

[nikku]

Thanks for opening this issue. Could you share a quick screenshot mocking the desired behavior to establish further context?

[tobiasschaefer]

Hi @nikku ,

thanks. I updated the "Additional context" section of the issue. I hope that makes it clearer.

[nikku]

Thanks @tobiasschaefer. Makes a lot of sense, I think.

[pinussilvestrus]

Thanks @tobiasschaefer, moving it to our HTO Inbox so we can consider it :+1:

cc @christian-konrad @marcosgvieira

[pinussilvestrus]

Implementation note: defaultValue can have different entry types depending on the form field. E.g. for selects, it is a select entry. In that case, we'd need to contribute a FeelSelectEntry in order to support the switch between select and FEEL.

[Skaiir]

What kinds of use cases do you have in mind @tobiasschaefer specifically? Is the data binding on its own not sufficient for defaulting? Or do you need like, maths in your initialization?

Doing a one time feel evaluation on transient variables feels like odd design to me, but perhaps I'm missing something.
Or is the idea that we re-evaluate the defaults when options change?

Then there's the problem of restriction. Allowing feel for single-select components for example doesn't make that much sense as you can in any case just use variables which are defined as options, and if you have those available you might as well just pass them via the key.

For multi select it's a similar situation.

So I think this requires a little bit more thinking before we decide on how to proceed there.

[tobiasschaefer]

Thanks @Skaiir

In our case we're doing maths, i.e. initializing a field with =get value(mymap, mykey).

Alternatively in this simple use case, we could introduce a new variable with an input mapping, initialize that using the FEEL expression, and then use that new variable. However it make it more complicated as it could be.

However: Actually, we have a custom UI which does exactly what you say: we re-evaluate the default when other fields change, specifically in this case the dropdown which defines "mykey". In this case the workaround with the input mapping no longer works because it needs to be more dynamic, i.e. based on the user input.

This is a simple mockup:

To be honest: I cannot quite follow on your "problem of restriction". Maybe I'm missing some details but hopefully my example above helps.

[barmac]

I think this is a valid feature request. I am moving this to backlog until somebody picks this up. The implementation would probably happen in https://github.com/bpmn-io/form-js repo.

[volodymyr-melnykc]

This request was also brought up during the user interview: https://github.com/camunda/users-feedback/issues/313

[jonathanlukas]

I have a similar use case:

Based on the value of another field, the default value of a field should be adjusted. Here, the interesting question is: How would the re-evaluate behave if there is already a value present on the field?

My thoughts went in this direction:

• the field is empty -> apply default (this would also help to populate a default value for a dropdown with dynamic options)
• the field is populated:
  • with the old default value -> apply new default
  • with a user-defined value -> do not apply the new default (this behaviour could be controlled with a checkbox "always override" that would enable that also a user-defined value would be overridden)

[tobiasschaefer]

Regarding @jonathanlukas comment: I fully agree.

Additionally, the question is also: when is the re-evaluation triggered and how do we prevent endless loops?

[christian-konrad]

I found use cases for this as well. One is creating read-only fields with calculated values, and use these values as intermediate values for further calculations or validations.

We move it into planning.

What I think the ideal behavior is:

https://github.com/camunda/camunda-modeler/assets/56470362/7144ef59-888b-44d1-9044-390cdfb9440e