bug Checkbox weirdness

[Gareth Cantrell]

There is something odd going on when using checkbox custom fields.

Sometimes the raw values are saved to the custom field, sometimes the display values, sometimes both the raw and display values are saved and sometimes a combination of raw and display values (where some selected options will use the raw value and others the display value within the same field!)

There seems to be no rhyme nor reason as to which values get stored when.

This is causing unpredictable behaviour in the workflows when we try use these values to make decisions.

 

[Berto2002]

Watching.

• When did this start?
• Are you referring to the dynamic checkboxes in ICF where you name the fieldID as h_custom_x and then how you pick-up and use those values in workflow?
• My understanding is that setting the field ID as above always results in the Display going into the field and thus if you want the Raw in the field you use an alternate field ID and then use workflow to populate it

[Gareth Cantrell]

We have a node in the workflow which specifically sets the "value" of the ICF field, however when I look at the database, I see random combinations of value/display stored.

The checkboxes are controlled via a Simple List.

I have a suspicion (currently unconfirmed) that when the field is edited in the request view details section, that is storing display value, which is why I'm seeing these strange combinations in the database.

Saying that though, I would expect the entire field to be overwritten, so I'm not sure why there is the inconsistency where both values and display strings are stored (especially considering we force the custom field to update using the ICF value).

[Sam P]

I'm not sure if this applies to your scenario but there are definitely differences when processing value/display field outputs in a normal IC field compared to a Human Task output field - I've had to make a note so I can be sure to get it right each time

[Gareth Cantrell]

My issue is more about when someone updates the checkboxes in the request Details panel - there is no way to capture that update in a workflow and force the use of the "value" rather than the display text

[Gareth Cantrell]

Another update on this - I've just received another "Incident" where the IC details "raw value" was retrieved in the workflow and saved to the custom field.

When the user updated this field from the request view (Details panel), the raw values were replaced by the display values - as I mentioned previously, we cannot control edits in the Details panel from the workflow, so we now sit in a dilemma where the wrong values are now stored in the field.

The behaviour of checkboxes seems entirely inconsistent and if this is not going to be fixed anytime soon, can someone please let me know how I can maintain consistency in these fields as we rely on the values for decisions later in the workflow.