Opened 14 years ago

Closed 11 years ago

Last modified 9 years ago

#13776 closed Bug (fixed)

is_valid() with null field value on ModelForms from models with non-nullable ForeignKeys causes ValueError

Reported by: Peter Bengtsson Owned by: ANUBHAV JOSHI
Component: Forms Version: dev
Severity: Normal Keywords: ModelForm ForeignKey
Cc: Roman Barczyński, Mjumbe Poe, anubhav9042@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

See this email for a longer description and a traceback.

In summary:
If you try to use a ModelForm to create a form without the intention of running the save() method it will raise a ValueError when you call is_valid(). This is because the ForeignKey field has a setattr override which prevents it from being None at all, ever. When you're just testing the form it should wrap this in a case so that it doesn't immediately complain.

Attachments (1)

13776.diff (3.9 KB ) - added by ANUBHAV JOSHI 11 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 by Łukasz Rekucki, 14 years ago

Triage Stage: UnreviewedAccepted

comment:3 by Joshua Ginsberg <jag@…>, 14 years ago

Summary: is_valid() on ModelForms on models with ForeignKeys cause ValueError rather than Falseis_valid() with null field value on ModelForms from models with non-nullable ForeignKeys causes ValueError
Triage Stage: AcceptedDesign decision needed

In #6886 with r8185 we introduced the requirement for the reverse descriptor that null and wrong-model assignments to ForeignKey fields would be disallowed prior to save-time. In r12098 with the model-validation merge, we changed the operation of ModelForms to construct instances at validation time, not at save-time. The combination of these two limits the developer's ability to preeempt the automated validation with ForeignKeys. For another example, see this other thread - a user's model populates a non-nullable FK with an overridden save method which would satisfy the not-null requirement, but the ModelForm created by the admin throws an error before save-time.

This requires some core developer time to figure out how to proceed.

comment:4 by Roman Barczyński, 14 years ago

Cc: Roman Barczyński added

comment:5 by Julien Phalip, 14 years ago

Severity: Normal
Type: Bug

comment:6 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:7 by Aymeric Augustin, 13 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:8 by Claude Paroz, 12 years ago

#18441 was a duplicate

comment:9 by Jacob, 12 years ago

Triage Stage: Design decision neededAccepted

comment:10 by Karol Sikora, 12 years ago

Owner: changed from nobody to Karol Sikora
Status: newassigned

comment:11 by Mjumbe Poe, 11 years ago

Cc: Mjumbe Poe added

comment:12 by ANUBHAV JOSHI, 11 years ago

Owner: changed from Karol Sikora to ANUBHAV JOSHI

comment:13 by ANUBHAV JOSHI, 11 years ago

Currently if blank=True and null is not True, ValueError is raised. The check being in related.py #399 for ForeignKey.
a.) I think we can display a correct message depicting the problem that in ForeignKey with null=True can only be left blank.
b.) We can stop the usage of blank=True with ForeignKey, because alone without null=True defined it has no significance and give suitable error message instead of raising an error. null=True alone works perfectly

Any opinions?

Version 0, edited 11 years ago by ANUBHAV JOSHI (next)

comment:14 by ANUBHAV JOSHI, 11 years ago

Cc: anubhav9042@… added

comment:15 by ANUBHAV JOSHI, 11 years ago

I hope to work on this ticket for GSoC 2014.

comment:16 by Tim Graham, 11 years ago

I think blank=True with null=False is acceptable. For example, you might fill in the value of the ForeignKey in the object's save() method.

in reply to:  16 comment:17 by ANUBHAV JOSHI, 11 years ago

Replying to timo:

I think blank=True with null=False is acceptable. For example, you might fill in the value of the ForeignKey in the object's save() method.

What about is_valid in case of ModelForm?

Last edited 11 years ago by ANUBHAV JOSHI (previous) (diff)

comment:18 by Tim Graham, 11 years ago

We should try to fix it so that an exception is not raised. As noted in the django-users thread, the use-case worked in Django 1.0, but broke in 1.2.

by ANUBHAV JOSHI, 11 years ago

Attachment: 13776.diff added

comment:19 by ANUBHAV JOSHI, 11 years ago

Has patch: set
Version: 1.2master

comment:20 by Tim Graham, 11 years ago

As discussed on IRC, the patch isn't what we want. There shouldn't be a form error because the form is valid according to its specification.

comment:21 by Tim Graham <timograham@…>, 11 years ago

Resolution: fixed
Status: assignedclosed

In 45e049937d2564d11035827ca9a9221b86215e45:

Fixed #13776 -- Fixed ModelForm.is_valid() exception with non-nullable FK and blank=True.

Thanks peterbe for the report.

comment:22 by Claude Paroz <claude@…>, 9 years ago

In 65a1055:

Fixed #25431 -- Readded inline foreign keys to modelformset instances

Too much field exclusions in form's construct_instance() in _post_clean()
could lead to some unexpected missing ForeignKey values.
Fixes a regression from 45e049937. Refs #13776.

comment:23 by Claude Paroz <claude@…>, 9 years ago

In 158b0a28:

[1.8.x] Fixed #25431 -- Readded inline foreign keys to modelformset instances

Too much field exclusions in form's construct_instance() in _post_clean()
could lead to some unexpected missing ForeignKey values.
Fixes a regression from 45e049937. Refs #13776.

Backport of 65a1055a3 from master.

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