#12858 closed (fixed)
Callable default on DateField + custom date format = widget._has_changed always true, forms fail to validate
Reported by: | Daniel Marohn | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | dateinput format | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have a ModelFormset
with some extra forms. The model the forms are based on contains a DateField
with default=datetime.date.today
, and other fields which are required. It must be possible to submit the formset without filling in all extra forms (which wouldn't validate when empty, due to the fact that there are required fields), so the formset sets empty_permitted
on the extra forms: this lets those forms skip validation as long as their fields have not changed (if self.empty_permitted and not self.has_changed())
in BaseForm.full_clean
. So far this is all standard formset behaviour.
I need to render the dates in a custom (ie local) format, so I have an __init__
method on my modelform which replaces the widgets of DateField
s with a DateInput
created with the desired format. This is also rather standard widget customization.
However, this causes Django to incorrectly treat every instance of the form as changed. The problem stems from the fact that Django compares the current data and the initial data in string form. Since the model DateField
has a callable default, it generates a form field with show_hidden_initial
set to True; this causes the form to store the initial value in a separate hidden widget, created by calling hidden_widget on the field. This corresponds to the HiddenInput
class for most formfields, including DateField
. When HiddenInput
renders, it formats the date using the default ISO format instead of the custom format used by the corresponding DateInput
. Therefore, DateInput._has_changed
sees two different strings (eg 2010-02-13 vs 13/02/2010), and thinks the field has changed even when it has not. In some cases, it may also think it has not changed when it has: for example, when one format is D/M/Y and the other is M/D/Y, and the user happens to change the date from Feb. 1 to Jan. 2 (01/02/2010 vs 01/02/2010).
The patch fixes this problem by having DateInput._has_changed
attempt to parse the initial value using the same format used by the HiddenInput
. If the initial value was a string, and was in that format, then it is converted to a date object, which is later converted back into a string using the DateInput
's own format; otherwise, everything remains as before.
Attachments (2)
Change History (8)
by , 15 years ago
Attachment: | django_datefield_has_changed_fix.diff added |
---|
comment:1 by , 15 years ago
Needs tests: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 15 years ago
Description: | modified (diff) |
---|
comment:3 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
by , 15 years ago
Attachment: | 12698-backport.diff added |
---|
I don't think this is the correct way to backport this, but the real way might be too hard to be worth it.
comment:4 by , 15 years ago
comment:5 by , 15 years ago
Actually, nevermind. 12698-backport.diff probably is the right fix because I don't think force_unicode on a datetime, date, or, time will use a locale-specific format. If I'm wrong about that, the fix applied to 1.1.X is incorrect.
patch fixing the bug