#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 |
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
Attachments (1)
Change History (22)
comment:1 Changed 3 years ago by
| Description: | modified (diff) |
|---|
Changed 3 years ago by
| Attachment: | dont_modify_final_attrs.diff added |
|---|
comment:2 Changed 3 years ago by
| Has patch: | set |
|---|---|
| Needs tests: | set |
comment:3 Changed 3 years ago by
comment:4 Changed 3 years ago by
| Needs tests: | unset |
|---|
comment:5 Changed 3 years ago by
| Owner: | set to Peter Andersen |
|---|---|
| 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 Changed 3 years ago by
| Component: | contrib.postgres → Forms |
|---|
comment:7 Changed 3 years ago by
| Patch needs improvement: | set |
|---|
comment:8 Changed 3 years ago by
| Patch needs improvement: | unset |
|---|
Suggested changes applied to the PR: https://github.com/django/django/pull/12193
comment:10 Changed 3 years ago by
Isn't this a possible data corruption issue worth to be backported?
comment:11 Changed 3 years ago by
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:12 Changed 3 years ago by
I'll make some PRs to backport the fix to the various active releases.
comment:13 Changed 3 years ago by
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