"Single on/off checkbox" widget makes no sense for boolean fields with cardinality > 1 and "Check boxes/radio buttons" makes little sense for boolean fields with cardinality > 2

Comment alters the form to limit to one, perhaps we can create a solution they can share

The field itself with a cardinality > 1 does make sense. It's the checkbox widget that doesn't.

But do we have a way to limit widgets depending on the field configuration?

Hmmm we used to have behaviors in D7 hook_field_widget_info that got removed in D8, not entirely sure if this has anything todo with this

Related issues:

#2047997: Get rid of field_behaviors_widget()
#2056405: Let field types provide their support for "default values" and associated input UI

Note - I hardly think this qualifies as a critical bug though .. :)

Yeah, not critical IMHO and was discussed in the list_boolean/boolean merge issue too.

Agreed that it is not critical. It is goofy though.

But do we have a way to limit widgets depending on the field configuration?

We do now.

Assigning to @yched to get his attention, we've been discussing/talking about this multiple times.

So, right, boolean widgets and checkboxes have long been a pain with multiple values.

@Damien Tournoud #4 is still true IMO

The field itself with a cardinality > 1 does make sense. It's the checkbox widget that doesn't.

I think we should rather work towards having dedicated widgets for the boolean field type that work OK with multiple fields.

- The decicated BooleanCheckboxWidget currently explicitly only works on the 1st value - checkboxes are painful for multiple values, because they have no "3rd state" for "neither yes or no, just no value". So just displaying it means a value will get saved on submit.

- The "generic" OptionsButtonsWidget works on list_* field types and also on booleans, but similarly isn't a great fit for booleans. Also, boolean field type is no longer part of the list_* family. IMO we should remove booleans from that widget and have a new, dedicated BooleanRadioWidget, which displays "yes / no" radios (which you can leave unchecked for "no value") for each delta.

--> BooleanCheckboxWidget would still be the usual widget for mono-valued bool fields,
and BooleanRadioWidget is the one for multiple-valued widgets ?

We now have WidgetInterface::isApplicable(), that can be used so that BooleanCheckboxWidget is not available for multi-valued fields ?

I actually started some work on #9 a while ago in a branch somewhere.
Didn't finish, but I could try to un-stale it for now...

I just tested this issue, I'm able to add a boolean field with the cardinality of 3 (or making the field with unlimited values), but still I'm getting only one checkbox when adding/editing the node. I believe this is still a issue that needs to be fixed. I tested on 8.0.x HEAD. Personally I believe we should not have cardinality setting to a boolean field.

(Updating issue credit for the major triage.)

I updated the IS with more detail based on what's been said in the comments of this issue, and from my own research.

Thanks @aditya.ghan for helping triage this.

The core committers discussed this issue today after several of the entity and field API maintainers had a chance to look at it. In terms of the field system, this would just be a normal bug (and the behavior has like this since CCK days so it is nothing new). However, this is primarily a usability problem. @alexpott even said that when he first started using Drupal, this bug caused him a lot of difficulty and confusion.

So, we'd like a usability maintainer's input on whether this is a major usability bug. Deferring triage on that. The summary is a little dense, so can we help the usability review by adding annotated screenshots showing the problem?

I looked up cardinality but still not sure what it means here. Number of allowed values?

@yoroy, yep, exactly.

Yes, I think this is major. I would like to have an example of where boolean field with multiple allowed values makes sense. My understanding of boolean is that it's always and only a yes/no, 0/1. How would multiple values work? yes/no/maybe or multiple sets of yes/no? I added "Define scenarios/use cases" to the remaining tasks in the issue summary.

No time for a deep dive at time of posting, but yes, lets keep this major please.

Would it be best to block bool fields from having cardinality to begin with? It does seem odd to ask the question 'choose yes or no' more than once in in almost any form context.

#20 yes, not, maybe: of course the field should be a select or radioS.
I do know that often enough, a request to build a form comes from 'a designer/the design team' who may not truly understand html form elements, then a dev needs to build a thing to match the design..

Just adding a note that I built a form with multiple booleans on a D7 this week. Only to discover that it doesn't work. :-)

This is a e-learning/e-health scenario. I have an entity with a two-step form, where the content of step two is dynamically generated using data from step 1. Labels and other info is sourced from step 1. What I need in the submitted form from step 2 is a series of booleans. (ie. True, False, True). I use form_alter to modify the boolean field to fit my purposes. However, it's all in vain as no false values are stored, in the series becomes true, true.

The case is not exactly mainstream, and there are plenty of other ways to solve the problem. If cardinality was hardcoded as 1 on booleans I wouldn't have tried this solution. So that would be better than current situation.

But at heart I feel that developers shouldn't make unnecessary assumptions, and just make the system work logically. And in this case that is to make single checkboxes with multiple cardinality appear as a pile of checkboxes with the exakt same label, potentially with remove and add_more buttons.

I cannot find any real example where boolean field with multiple allowed values makes sense... Even if there's a case where multiple allowed values are needed, other types of list field should be used rather than boolean, I believe. So +1 for "to block bool fields from having cardinality".

Added screenshots of current state to IS.

Adding #2619328: A required boolean field behaves differently depending on the widget as related, that issue has much more traction so suggested that we merge them and then can close this as a duplicate.

Reviewed this in light of #34 and agree this can be closed as a duplicate for the following reasons:

• both issues are major
• both are addressing the same problem space
• the linked issue has a patch
• the linked issue has input from entity-field maintainers

thanks @pameeela, credited yourself and @aditya.ghan over there

If anyone disagrees with this assessment, please re-open, but I note one month has passed since ##3 so I take that to be there are no objections.