A required boolean field behaves differently depending on the widget

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Picking up again. Summarising all the comments and feedback so far.
- Re-rolled the patch.
- Added two test cases to validate the field widget settings and behaviour of checkbox option on the form.
- Re-roll diff mostly contains the test cases added by me.
- Keeping "needs tests" tag to see if we need further tests.

Happy to add additional test cases based on feedback from folks.

Pending action items:
#63 Needs some review from usability team.
#59 We need to address feedback from @joachim.
I tried to made sense of the description, however this is there since beginning so I think @tstoeckler is the right person to comment on that.
#56 Second point. I think someone with more command over english can rephrase it. I am somewhat confused it.

Regarding the comment: Yes, @joachim in your words because you can never unset a value with a checkbox. I actually tried to explain the situation in the comment directly preceding that line that is quoted in #59. Re-reading it again now I think one thing that is missing in that whole comment is that for Drupal a required field means that it has a value, which in case of boolean fields may include FALSE. Maybe the following table will make clear what I'm trying to get at (and what this issue is about):

The problem is that both scenarios have valid use-cases, the first one is, for example, "Do you want to receive our newsletter?" where it totally makes a difference whether someone has explicitly said "No" or not yet made a choice. The second is "Do you agree to the terms of service?" where that distinction is meaningless and the "required" aspect really means the "Yes"-value is required.

To make things even more confusing you can actually model both things with Drupal form displays already. In both cases you configure the boolean field to be required and in the first case you choose the radios widget so that the user can explicitly choose the "No"-value and in the second case you choose the checkbox widget.

And that is exactly what this issue is about: The choice of widget should not be a determining factor for the data model. It should only control how the data is input, not what kind of data is valid.

Now from a pure data modelling perspective we could just say "the checkbox widget is doing it wrong" and just never mark the checkbox input required. Since the checkbox input would effectively still yield a FALSE value, this would be in-line with the field being required from a Field API perspective. But that would mean we would break the second (terms of service) use-case which has worked since (at least) Drupal 8.0.0 so that is presumably not a viable option.

So this patch attempts to rectify the situation by adding a setting to the checkbox widget which basically lets you choose between the two scenarios. In terms of the table this then becomes:

Hope that makes the situation more clear.

Not sure how exactly the comment in the code should be updated, but my suggestion would be to add something like "for Drupal a required field means that it has a value, which in case of boolean fields may include FALSE." to the beggining of the paragraph.

Fixing the CCF issues with #69

The last submitted patch, 71: 2619328-71.patch, failed testing. View results →

Fixing the test case failures.
I think it was related to incorrect namespace path.
Test is already passing on local.

What's a use case for a required Single On/Off checkbox? If the user is required to check it why not just make the default value be true?

Agree it's weird you can make the boolean required and if you use that widget it can be saved without checking just having a hard time with the use case. Maybe some warning text on the field setting for a boolean could be used?

What's a use case for a required Single On/Off checkbox? If the user is required to check it why not just make the default value be true?

Something like a data privacy or terms of service agreement. Even though you cannot submit the form without checking the box, you need to make sure that the user explicitly checks the box and you need to have a record of that.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Update patch for 10.3.0

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/BooleanCheckboxWidget.php
@@ -38,6 +39,23 @@ public function settingsForm(array $form, FormStateInterface $form_state) {
+    // Strictly speaking the checkbox widget should only be available for
+    // required field definitions in the first place, but enforcing this would

Why?

I don't understand this at all.

If the checkbox is 'Agree to site terms and conditions' then yes.

But a checkbox could be 'Promote to front page' or 'I want a child meal'.

Re #79: That's the entire point of this issue: For those examples that you mentioned there is no point in distinguishing between the off-value ("Do not promote this to the front page" / "I do not want a child meal") and no value ("Not known whether to promote this to the front page or not" / "Not sure if I want a child meal"). And in terms of Field API "required" means "there must be a value", not necessarily "the on-value / yes-value / ... must be chosen". And if you do in fact want to allow making a distinction between the off-value and no value then the checkbox is not a suitable widget for that, because it inherently cannot make that distinction.

That said, I absolutely welcome any suggestions on improving the in-code documentation, as apparently it's not as clear as it could be.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-07-12 Needs work . That issue will have a link to a recording of the meeting. For the record, the attendees at today's usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first thanks for working on the issue. In general we had a clear consensus that this feature is useful and the implementation looks good.

In regards of the question in #63 🐛 A required boolean field behaves differently depending on the widget Needs work , we've agreed to go with Require changing the string to Require the user to select the checkbox.. That way, the label would be consistent with the other label Use field label instead of the "On" label as the label. on that form display widget.

And we've noticed a detail about the single on/off radio buttons option, which is out of the scope for this issue. If you create a boolean field, set the form display widget to Single on/off radio buttons, then set the field to required within the field settings, and check the Set default value checkbox, you then get three options: N/A, Off, and On. With the Required field checkbox checked the only possible options are either Off and On. If you now set the default value to N/A, save, and reopen the field setting you will notice that the previously ticked Set default value checkbox got unticked and the Set default value checkmark got dropped again. If you take a look at the configuration for the field you notice either way if the Set default value checkbox is checked without an option or with N/A, default_value: { } remains empty after saving the field settings. So the N/A option is sort of without any purpose except the potential to confuse user and it would be way more clear if the N/A option would be removed from the list of options when a boolean field is required. But that should be moved to a follow up issue.

Awesome, that's great to hear, thanks for the usability review to all those involved. Will try to get an updated MR going here soon, but can't promise anything...

Update patch for 10.3.5