Form Radio Button status and values can be out of synch

[stefanvogel65]

Subject of the issue

When using radio buttons on forms in the workflows, the status of the radio button widget and the actual value can be out of synch, e.g. a radio button looks to be set to a specific selection although the variable associated with the radio button is not set. Under some circumstances, similar inconsistencies appear for drop-down lists, however more rarely.

Your environment

Tried on Proxeus core on RHEL v 7 and with different browsers (Firefox, Chrome).

Steps to reproduce

Import the testing workflow to Proxeus and insert the ODT template to the Proxeus template “Test Template” and run it.
The testing workflow’s key form is the “Test-Input” Form where two radio buttons and two drop downs are inserted, one of each with default values set and one with no default value. There are three ways to check on the actual status of the variables behind the radio buttons and drop downs:

1. Headline components that only appear when certain values are set
2. A template that lists the variable settings in the workflow
3. A conditional node that branches to one of two static forms depending on the value of DropDown1

Start the workflow and compare the elements on the form with what the rendered template shows. Proceed to the next form to check whether the variable of RadioButton2 is actually set to “1st value”. Change settings of the drop downs and radio buttons on the form and compare with the rendered template.

When you complete a workflow instance and start a new one, the behavior is slightly changed. Also, there might be a different initial form status when you start a workflow instance as another user.

Depending on the constellation (new/existing user, 1st or second instance of a workflow, …) the behavior can be different. E.g. it might be that the conditional components on the form appear as expected, however the variables in the rendered document are not set.

See attached word document for screenshots from some testing scenarios.

Expected behavior

The status of the radio buttons and drop downs as they appear on the form should always be in synch

• with the conditional elements shown on the form,
• with what the values in the rendered document are and
• with what is evaluated in the conditional node of the workflow.

Actual behavior

There are constellations where the drop downs and / or radio buttons appear to be set to a specific value, but these values

• are not displayed in the rendered document,
• do not result in the corresponding display of the conditional form components, and
• are not evaluated as they should in the conditional nodes in the workflow.

In particular, on startup of the first workflow instance, RadioButton1 looks as if is set to “1st value” (as it should, as this is the default setting), however neither the conditional Headline component is displayed, nor the corresponding value in the rendered form is set, nor the conditional node leads to the expected next form “Test Output”.

Find the following in attached zip file Test-Artefacts.zip

• Exported Proxeus Workflow: Proxeus-Workflow_08a844a4-633a-4b95-afa9-be23e584cd4c_22-12-2020_17-51.db
• Details of the scenarios tested with screenshots: Testing Radio Buttons and Drop Down Behavior.docx
• Template ODT file to use in the corresponding Proxeus template: Test-Template.odt

[loleg]

@stefanvogel65 thank you very much for this detailed and clear problem description.

ZIP files with binaries, however, are generally discouraged in bug reports, as they can be a source of viruses. I am holding on to a copy of the files myself, and will be happy to provide it to a developer on request. But it would be ideal if you could put the screenshots directly into a comment rather than in a Word file. Knowing the version of the browser that it is taken in might also help.

We will look into this and try to analyse the cause as soon as we can.

[stefanvogel65]

@loleg thank you for looking into this.

On the ZIP attachment: I choose a zip as at least the workflow export (Proxeus *.db file) cannot be attached otherwise.

The browsers I tried are:

• Firefox 84.0.1 (64-bit)
• Google Chrome 87.0.4280.88 (Official Build) (64-bit)

I put the content of the Word attachment here for convenience. Please let me know in case you need something else.

Testing Radio Buttons and Drop Down Behavior

Stefan Vogel, 22 Dec. 2020

Test Workflow

Get the details from Proxeus-Workflow_08a844a4-633a-4b95-afa9-be23e584cd4c_22-12-2020_17-51.db in the ZIP attachment.

Test scenario 1, fresh start

Initial screen

Issues

• Conditional Block for RadioButton2 = “1st Value” is not displayed on form.
• Values in rendered document are not set (empty), even though RadioButton1 looks as if it is set to “1st Value”. DropDown1 is supposed to show value “empty” for “Select…”:

Test scenario 2, 2nd run, all correct

DropDowns and RadioButtons are selected as shown, conditional blocks all appear as they should.

Rendered form is filled correctly:

Proceeding to the next form: Conditional node performs correctly:

Test Scenario 4, restart after document delete

Form initialized as expected, however, conditional Block for RadioButton2, 1st Value is hidden.

Rendered Doc does not show value for RadioButton2, in contrast to what is expected.

Navigating to the next form shows that RadioButton2 value is not set to “1st Value”:

Test Scenario 5, Logged in with different user (Metamask)

Create new document from same workflow. Values seem to be inherited from pending draft from other user, conditional Blocks on form look consistent to the values pre-selected:

However, rendering does not show any radio button or drop down value set:

Test Scenario 6, Another fresh start

Started a new document, form initializes like this:

Observation:

1. RadioButton2 set to default value “1st Value”, as expected.
2. Conditional Block for RadioButton2 for “1st value” is hidden
3. Drop downs set to 1st value, even though DropDown1 expected to be not set.
4. Rendering does not show any value for Radio Buttons or Drop Downs:

[loleg]

We started a new investigation to this issue, since we had a better idea of how to address it. A fix is in the works.

[slavas490]

done

[loleg]

The fix has now been released