Opened 5 years ago

Closed 13 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 13 months ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 5 years ago by lrekucki

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

comment:3 Changed 5 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 5 years ago by romke

  • Cc romke added

comment:5 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to Bug

comment:6 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:8 Changed 3 years ago by claudep

#18441 was a duplicate

comment:9 Changed 2 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

comment:10 Changed 2 years ago by elektrrrus

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

comment:11 Changed 2 years ago by mjumbewu

  • Cc mjumbewu added

comment:12 Changed 16 months ago by anubhav9042

  • Owner changed from elektrrrus to anubhav9042

comment:13 Changed 16 months 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 16 months ago by anubhav9042 (next)

comment:14 Changed 16 months ago by anubhav9042

  • Cc anubhav9042@… added

comment:15 Changed 16 months ago by anubhav9042

I hope to work on this ticket for GSoC 2014.

comment:16 follow-up: Changed 14 months 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 14 months 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 14 months ago by anubhav9042 (previous) (diff)

comment:18 Changed 14 months 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 13 months ago by anubhav9042

comment:19 Changed 13 months ago by anubhav9042

  • Has patch set
  • Version changed from 1.2 to master

comment:20 Changed 13 months 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 13 months 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.

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