Opened 6 years ago

Closed 2 years ago

Last modified 10 months ago

#13776 closed Bug (fixed)

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

Reported by: peterbe Owned by: anubhav9042
Component: Forms Version: master
Severity: Normal Keywords: ModelForm ForeignKey
Cc: romke, mjumbewu, 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 anubhav9042 2 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 6 years ago by lrekucki

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 6 years ago by Joshua Ginsberg <jag@…>

  • Summary changed from is_valid() on ModelForms on models with ForeignKeys cause ValueError rather than False to is_valid() with null field value on ModelForms from models with non-nullable ForeignKeys causes ValueError
  • Triage Stage changed from Accepted to Design 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 Changed 6 years ago by romke

  • Cc romke added

comment:5 Changed 5 years ago by julien

  • Severity set to Normal
  • Type set to Bug

comment:6 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:8 Changed 4 years ago by claudep

#18441 was a duplicate

comment:9 Changed 3 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

comment:10 Changed 3 years ago by elektrrrus

  • Owner changed from nobody to elektrrrus
  • Status changed from new to assigned

comment:11 Changed 3 years ago by mjumbewu

  • Cc mjumbewu added

comment:12 Changed 2 years ago by anubhav9042

  • Owner changed from elektrrrus to anubhav9042

comment:13 Changed 2 years ago by anubhav9042

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 2 years ago by anubhav9042 (next)

comment:14 Changed 2 years ago by anubhav9042

  • Cc anubhav9042@… added

comment:15 Changed 2 years ago by anubhav9042

I hope to work on this ticket for GSoC 2014.

comment:16 follow-up: Changed 2 years ago by 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.

comment:17 in reply to: ↑ 16 Changed 2 years ago by anubhav9042

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 2 years ago by anubhav9042 (previous) (diff)

comment:18 Changed 2 years ago by timo

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.

Changed 2 years ago by anubhav9042

comment:19 Changed 2 years ago by anubhav9042

  • Has patch set
  • Version changed from 1.2 to master

comment:20 Changed 2 years ago by timo

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 Changed 2 years ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 45e049937d2564d11035827ca9a9221b86215e45:

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

Thanks peterbe for the report.

comment:22 Changed 10 months ago by 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.

comment:23 Changed 10 months ago by 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.

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