Code

Opened 8 years ago

Closed 7 years ago

#3130 closed defect (duplicate)

Fix for BooleanFields in newforms

Reported by: ben <ben.dean.kawamura@…> Owned by: nobody
Component: Forms Version: master
Severity: normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

The BooleanField in the newforms library doesn't seem to work when required=True. If the user doesn't check the checkbox, it always fails the validation check. What should happen is the field should have it's value set to False.

Attachments (1)

boolfield.diff (357 bytes) - added by ben <ben.dean.kawamura@…> 8 years ago.
Here's a quick patch to fix the problem

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by ben <ben.dean.kawamura@…>

Here's a quick patch to fix the problem

comment:1 follow-up: Changed 8 years ago by adrian

  • Resolution set to invalid
  • Status changed from new to closed

This behavior is intentional. required=True on a checkbox means "the user must check the box."

comment:2 in reply to: ↑ 1 Changed 7 years ago by njharman@…

Replying to adrian:

This behavior is intentional. required=True on a checkbox means "the user must check the box."

That is weird, and far from "least suprise". Booleans have two vaules T/F, not checking a check box should be "False" not "Null"

If I want to accept true/false values in my newforms form I must add 'required=False' even though the field is in fact required and the related model will not accept a Null value.

Very strange.

comment:3 Changed 7 years ago by SmileyChris

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Design decision needed

Yes, this needs some more thought. Avoiding the required=True issue, if required is False then the field should clean to False, not None (easily achieved by moving the new code in this patch below the parent clean() call.

comment:4 Changed 7 years ago by mfenniak

Just got bit by this unintuitive behaviour, and I thought I would add my input. Fundamentally, I don't see why anyone would want a checkbox that is always checked. That sounds to me like "no option", and not something that belongs on a form. That behaviour for required=True is not intuitive. I suggest that:

If the BooleanField is required=True, that means "the user must select yes or no". This sounds like a pair of radio buttons (or alternatively, a select drop-down), yes and no, where neither is selected. This means that the user cannot avoid selecting an option, or else the form validation fails.

If the BooleanField is required=False, then it can be displayed as a checkbox.

The current behaviour is primarily broken because required=True is the default for all fields on a form. If you add a BooleanField, you now have to check it or else fail validation. There really isn't an option in the field.

comment:5 Changed 7 years ago by ubernostrum

Just wanted to point out that there are use cases for the current behavior; for example, a user-registration form might want to require the the user check an "I agree to terms of service" box before proceeding to account creation. Doesn't necessarily have bearing on what the default behavior should be, but there are definitely cases where the "must be checked" behavior is desirable.

comment:6 Changed 7 years ago by ben

I think the simplest way to change things is to make BooleanFields required=False by default. If someone wants to have a checkbox you must check to get to the next page, they can set required=True. But that seems like it will definitely be less used.

comment:7 Changed 7 years ago by Marty Alchin <gulopine@…>

I fought with this particular issue for a while, and I have to agree with ubernostrum and ben. I can definitely understand situations like "I agree to the terms of service" and "I am 30 years old or older" and maybe even "I hereby place this content in the public domain", but I can't imagine these to be the norm.

It does seem the W3C considered this to be the case, however, as their definition of successful controls lists checkboxes only in the "on" position. Naturally, browsers implemented this such that unchecked checkboxes aren't submitted at all, and it seems that Django is simply following suit.

In terms of the early Web, however, an unsubmitted checkbox rarely meant that a form was in error. Instead, it typically indicated that a particular bit of code wouldn't be processed. Throwing an error in this case would seem counter-intuitive to most developers, while those few situations that do in fact require a checked checkbox would easily merit an explicit required=True in the form definition.

comment:8 Changed 7 years ago by ubernostrum

  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #5104; let's get all this discussion into one place.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.