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

[Peter Bengtsson]

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.

[Karen Tracey]

Another scenario reported here: ​http://groups.google.com/group/django-users/browse_thread/thread/8ea803cb8a28e594#

[Joshua Ginsberg <jag@…>]

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.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Claude Paroz]

#18441 was a duplicate

[ANUBHAV JOSHI]

Currently if blank=True and null is not True, ValueError is raised. The check being in related.py line 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?

[ANUBHAV JOSHI]

I hope to work on this ticket for GSoC 2014.

[Tim Graham]

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.

[ANUBHAV JOSHI]

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?

[Tim Graham]

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.

[Tim Graham]

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.

[Tim Graham <timograham@…>]

In 45e049937d2564d11035827ca9a9221b86215e45:

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

Thanks peterbe for the report.

[Claude Paroz <claude@…>]

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.

[Claude Paroz <claude@…>]

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.