Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#24391 closed Bug (fixed)

UUIDField with default=uuid4 triggers validation on otherwise empty inline formsets

Reported by: Michael Angeletti Owned by: Tim Graham
Component: Forms Version: dev
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When using DateTimeField(default=timezone.now), inline model formsets know to avoid validation when no fields are changed, even though there is a value in that given DateTimeField. However, when using another field (UUIDField in my case) I'm getting inline form validation on otherwise empty forms, presumably due to the default UUID being different than the one generated during POST.

This is at least related to #24377, but since this isn't constrained to primary_key=True cases, it needs its own ticket. Could a general solution to this render a specific solution to #24377 moot, or are they two separate issues?

Digression

How does this if user changed the default datetime value: count the form as having been changed functionality work, btw? My understanding of dynamic default values like this is that there would be no way for Django to know whether the value has changed, unless the default value was included in a hidden field, or set in cache or cookies on page load... I'd love to document this, because if a user creates their own form field they might want to build in this sort of functionality.

Attachments (1)

validation-errors.png (174.7 KB ) - added by Michael Angeletti 10 years ago.
Inline validation errors with a UUIDField

Download all attachments as: .zip

Change History (9)

by Michael Angeletti, 10 years ago

Attachment: validation-errors.png added

Inline validation errors with a UUIDField

comment:1 by Tim Graham, 10 years ago

Owner: changed from nobody to Tim Graham
Status: newassigned
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

comment:2 by Tim Graham, 10 years ago

The root cause is that the default is called twice when rendering the field so the hidden initial value is different from what appears in the input. I think this bug was hidden with the common case of datetime defaults because microseconds are truncated so usually the two values are equal, although it seems like it should trip across a second boundary at some point.

Maybe we can evaluate the default on the form field, rather than the widget. Backwards compatibility is the main concern.

comment:3 by Michael Angeletti, 10 years ago

comment:4 by Tim Graham, 10 years ago

Has patch: set
Patch needs improvement: set
Severity: NormalRelease blocker

comment:5 by Tim Graham, 10 years ago

#11390 - If you use a callable as default value on a model field, it gets called 3 times - is related and probably addressed at least partially by this.

comment:6 by Tim Graham, 10 years ago

Patch needs improvement: unset

Updated PR

comment:7 by Tim Graham <timograham@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 65441bbdb02427655869c42791a0bc5a9c631292:

Fixed #24391 -- Made BoundField.value() cache callable values.

comment:8 by Tim Graham <timograham@…>, 10 years ago

In 278b6987943d0a610aadc767200651ec5d7d738e:

[1.8.x] Fixed #24391 -- Made BoundField.value() cache callable values.

Backport of 65441bbdb02427655869c42791a0bc5a9c631292 from master

Note: See TracTickets for help on using tickets.
Back to Top