#31073 closed Bug (fixed)
SplitArrayField with BooleanField always has widgets checked after the first True value.
Reported by: | Peter Andersen | Owned by: | Peter Andersen |
---|---|---|---|
Component: | Forms | Version: | 3.0 |
Severity: | Normal | Keywords: | SplitArrayField BooleanField ChecboxInput |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | |||
Description (last modified by ) ¶
When providing a SplitArrayField BooleanField with preexisting data, the final_attrs dict is updated to include 'checked': True
after the for loop has reached the first True
value in the initial data array. Once this occurs every widget initialized after that defaults to checked even though the backing data may be False. This is caused by the CheckboxInput widget's get_context()
modifying the attrs dict passed into it. This is the only widget that modifies the attrs dict passed into its get_context().
CheckboxInput setting attrs['checked']
to True: https://github.com/django/django/blob/master/django/forms/widgets.py#L527
Change History (22)
comment:1 by , 5 years ago
Description: | modified (diff) |
---|
by , 5 years ago
Attachment: | dont_modify_final_attrs.diff added |
---|
comment:2 by , 5 years ago
Has patch: | set |
---|---|
Needs tests: | set |
comment:3 by , 5 years ago
comment:4 by , 5 years ago
Needs tests: | unset |
---|
comment:5 by , 5 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
Summary: | SplitArrayField with BooleanField always has widgets checked after first True value → SplitArrayField with BooleanField always has widgets checked after the first True value. |
Triage Stage: | Unreviewed → Accepted |
Version: | 2.2 → 3.0 |
Thanks for the report.
Reproduced at 5708327c3769262b845730996ca2784245ada4d1.
comment:6 by , 5 years ago
Component: | contrib.postgres → Forms |
---|
comment:7 by , 5 years ago
Patch needs improvement: | set |
---|
comment:8 by , 5 years ago
Patch needs improvement: | unset |
---|
Suggested changes applied to the PR: https://github.com/django/django/pull/12193
comment:11 by , 5 years ago
It seems that it's a regression in b52c73008a9d67e9ddbb841872dc15cdd3d6ee01. I agree that this qualifies for a backport as a data loss bug to Django 3.0 (maybe also to 2.2 and 1.11).
comment:13 by , 5 years ago
Peter Andersen, you don't need to create fixes for other versions, commiters will backport fix (if necessary).
Changes available here: https://github.com/django/django/pull/12193