Opened 20 years ago

Closed 5 years ago

Last modified 5 years ago

#3482 closed Bug (wontfix)

MultipleChoiceField validation against a list with a single null element

Reported by: Jeff Bauer <jbauer@…> Owned by: nobody
Component: Forms Version: dev
Severity: Normal Keywords: MultipleChoiceField
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

MultipleChoiceField fails validation when required=False against a list with a single null value (as opposed to when value itself is null)

>>> f = MultipleChoiceField(required=False, choices=[('1', '1'), ('2', '2')])
>>> f.clean([''])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "django/newforms/fields.py", line 386, in clean
    if val not in valid_values:
django.newforms.util.ValidationError: [u'Select a valid choice.  is not one of the available choices.']
>>> 

Attachments (2)

4490.diff​ (941 bytes ) - added by Jeff Bauer <jbauer@…> 20 years ago.
3482.diff​ (936 bytes ) - added by Jeff Bauer <jbauer@…> 20 years ago.
replaces 4490.diff patch

Download all attachments as: .zip

Change History (9)

by Jeff Bauer <jbauer@…>, 20 years ago

Attachment: 4490.diff​ added

comment:1 by Adrian Holovaty, 20 years ago

Triage Stage: Unreviewed → Design decision needed

In your example, shouldn't f.clean(['']) return [] rather than ['']?

by Jeff Bauer <jbauer@…>, 20 years ago

Attachment: 3482.diff​ added

replaces 4490.diff patch

comment:2 by Jeff Bauer <jbauer@…>, 20 years ago

New patch. Clean now returns an empty list rather than the original value.

comment:3 by Jacob, 19 years ago

Triage Stage: Design decision needed → Ready for checkin

comment:4 by Malcolm Tredinnick, 19 years ago

Resolution: → fixed
Status: new → closed

This has already been fixed at some point in the interim (and we're testing it).

comment:5 by Joshua Smith, 5 years ago

Easy pickings: unset
Resolution: fixed
Severity: → Normal
Status: closed → new
Type: → Uncategorized
UI/UX: unset

This is still happening for me in Django 3.1.13:

>>> from django.forms import MultipleChoiceField
>>> f = MultipleChoiceField(required=False, choices=[('1', '1'), ('2', '2')])
>>> f.clean([''])
Traceback (most recent call last):
  File "/Users/joshsmith/.pyenv/versions/3.9.4/lib/python3.9/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
  File "/Users/joshsmith/code/course-platform/.venv/lib/python3.9/site-packages/django/forms/fields.py", line 150, in clean
    self.validate(value)
  File "/Users/joshsmith/code/course-platform/.venv/lib/python3.9/site-packages/django/forms/fields.py", line 883, in validate
    raise ValidationError(
django.core.exceptions.ValidationError: ['Select a valid choice.  is not one of the available choices.']

comment:6 by Tim Graham, 5 years ago

Has patch: unset
Triage Stage: Ready for checkin → Unreviewed
Type: Uncategorized → Bug

comment:7 by Carlton Gibson, 5 years ago

Resolution: → wontfix
Status: new → closed

So, it's hard to say about the dark-history here, as bootstrapping a very old environment is somewhat fiddly these days but ​the logic here is virtually unchanged from the ​earliest days of the MultipleChoiceField implementation. This behaviour is certainly unchanged as far back as Django 1.8. Without a serious case being made, the backwards compatibility concerns preclude changing this now.

However, for me, this is expected behaviour: '' is not a valid choice. If I want filtering of empty values then I'm expecting to use a widget to filter this in value_from_datadict, or else a field subclass, if I want the behaviour there. The default implementation is doing the right thing here rejecting the incorrect value.

Last edited 5 years ago by Carlton Gibson (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top