I have a very simple workflow where, upon process start, I use a Boolean Select to set true/false to a Boolean variable.
The process start form does set the variable properly (confirmed via REST), however, the “Review” user task embedded form, which also has a Boolean Select (for the same cam-variable-name), does not select the appropriate value (based upon the variable’s current true/false value), but behaves as if the variable is not initialized.
Should I expect to be able to use the Boolean Select to view/change existing an existing variable, or only to set an initial value for the variable?
create.txt (536 Bytes)
simple2.bpmn (2.8 KB)
review.txt (536 Bytes)
There shouldn’t be a problem with setting a variable on starting your processs and then viewing (or even editing) it from a user task.
Can you upload your BPMN file and embedded form and i’ll try to see what’s going wrong.
Thanks, I really appreciate the help.
The uploaded files are very simple. I’ve renamed the .html files to .txt to allow upload.
For this test, I was using curl to deploy, so I have the forms set as “embedded:deployment…” in the BPMN, however, the same problem occurs with WAR deployment and embedded:app:forms/…
I am using the Docker image and have tried with 7.9 alphas 1 and 3.
If, in review.html/txt, I replace the select with a checkbox, it works properly, reflecting the value of the Boolean variable initially set in create.html/txt.
the problem here is the data binding to the
<select>-field. The values of the options are not of type boolean, so the binding does only work in one direction correctly (that is, saving), because the engine is smart enough to convert the strings “true” and “false” to boolean values it knows that it should be boolean (what it does because of
You have (at least) two options to solve:
<input type="checkbox"> instead of select. Here the data binding works out of the box.
- Write a
<script cam-script type="text/form-script"> snippet that does the correct value-selection of the select-element.
- be even smarter (AngularJS-guys most likely have better solutions)
Thanks @Ragnar, for confirming that this is the expected behaviour.