Should checkboxes support true/false?

[nkylstad]

Description

We had an incident with an app with several checkbox-components, each with only 1 option to check. The data model fields were all booleans, so that checking the checkbox set the value to true. App: digdir/godkjenn-bruksvilkaar.

However, after this change (from january 2021) Altinn/altinn-studio@0bd246a#diff-df4b204405101ca09583792727c63870fcf2a486381a2575ca8eb334a33f2660, checkbox components no longer support toggling true/false. They only support toggling either options-value, or no value.

In the specific incident mentioned above, this caused problems because the underlying data model fields were not nullable booleans, and when the data model was initialized, they were automatically set to false. Checking the checkbox then resulted in a value false,true, since toggling between true/false is not supported. This results in a validation error, since false,true is not a boolean value.

We need to decide if toggling true/false is behaviour we would expect from a checkbox, and if so, implement support for it.

Screenshots

Considerations

Is togglig between true/false behaviour we expect from a checkbox? Or is this better covered by f.ex. a radiobutton (Yes/No), where the user actively has to choose? Is togglig between value/no value as we do now sufficient for a checkbox?

Acceptance criteria

Describe criteria here (i.e. What is allowed/not allowed (negative tesing), validations, error messages and warnings etc.)

Specification tasks

• Development tasks are defined

Development tasks

Add tasks here

Test

Add test cases here as checkboxes that are being tested as part of the changes.

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

• Documentation is updated (if relevant)
  • Technical documentation (docs.altinn.studio)
  • User documentation (altinn.github.io/docs)
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

[mjulstein]

Checkboxes have 3 states. How we render them is something else...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox#indeterminate

[altinnadmin]

We need to decide if toggling true/false is behaviour we would expect from a checkbox

For simple checkboxes that is mapped to a boolean data element I guess it makes sense to support this kind of toggling. I would have expected us to handle this.

[nkylstad]

Checkboxes have 3 states. How we render them is something else...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox#indeterminate

@mjulstein Since we use Material-UI's checkbox components and don't implement the <input>-element directly, this is something that have to assume this is covered in the material-ui implementation.

The question here is whether unchecking a checkbox should be able to toggle a value (false). My initial thought was that no, this should not be something we support, but since this is something that we did (maybe inadvertently) support at one point, we need to do a consideration. Reading more in the docs you linked about the standard checkbox implementation, I still think that this is not functionality that should be covered by checkboxes, since the value that is submitted by a checkbox should only be included if the checkbox is checked.

For simple checkboxes that is mapped to a boolean data element I guess it makes sense to support this kind of toggling. I would have expected us to handle this.

@altinnadmin To support this we would have to implement custom handling of that specific case. If the user does not check the checkbox, then the value would never be set, and to get to false user would have to check, then uncheck the checkbox. (Unless the field in the datamodel, incl. any parent groups, is set as required in the data model, then data would be instantiated to false by default.) Wouldn't radio buttons with yes/no be a more logical choice in that case?

[altinnadmin]

If the user does not check the checkbox, then the value would never be set, and to get to false user would have to check, then uncheck the checkbox.

Yes, if a default value has not been set. If we look at this from a "data point of view", it makes more sense to be able to toggle a boolean field between true/false than true/empty. Checkboxes still are "the original true/false-togglers" in UI :)

But I see your point, just fearing this will be perceived as a lack of flexibility, that we're "forcing" the use of radio buttons on devs.

[Hannott]

In my mind this is asking if a thing should do what it was made to do. While it technically can have three states, in practice it's either true or false, and null should be treated as false, or you should be using a different component.

The component as it is now should be renamed "multiple choice checkboxes", and the standard checkbox component should work like a standard checkbox, true/false

[olemartinorg]

Highly relevant issue here, and possibly the reason booleans are not supported properly in app-frontend:

• Analysis: get rid of stringified form data in frontend? Produced JSON invalid against JSON-schema. #205

Fixing this properly is most likely a (very) breaking change, so this should be considered in #339

[FinnurO]

It seems clear that, according to the HTML specification https://html.spec.whatwg.org/#checkbox-state-(type=checkbox), we should only support true/false and not a third state.

So the tasks should be to follow the standard and implement boolean support as commented.