Opened 15 years ago

Last modified 14 years ago

#11807 closed

Admin inlines onetoone related object not saved — at Version 2

Reported by: nemesys@… Owned by: nobody
Component: contrib.admin Version: 1.1
Severity: Normal Keywords: admin inline onetoone save
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by Karen Tracey)

Hi there,

I have the following models:

class A(models.Model):
   id = models.AutoField(primary_key=True)

class B(models.Model):
   mya = models.OneToOneField(A, primary_key=True)
   text = models.TextField(default='Init')

In admin interface, I have used an inline to include B when
changing/adding an A. Adding/Changing an A without touching the B inline
results in A beeing saved, but not B. Changing the textfield from B into
sth other than default and it works, but I want the default beeing saved too.

Thanks!
Jean

Change History (3)

comment:1 by Adam Gomaa, 15 years ago

Component: Uncategorizeddjango.contrib.admin
Patch needs improvement: set

The attached patch against trunk adds a regression test that fails and shows the problem.

Note that when the submitted value is not the default value, it's saved correctly, so test_onetoone_pk_inline_changed passes. My guess is that BaseModelFormSet.save_existing_objects() is skipping the form because form.has_changed() is False.

by Adam Gomaa, 15 years ago

Patch that adds a regression test for this issue.

in reply to:  1 comment:2 by Karen Tracey, 15 years ago

Description: modified (diff)
Triage Stage: UnreviewedDesign decision needed

First, I fixed the description formatting. Please use preview (and wiki format) to make sure things are readable before submitting.

Replying to AdamG:

My guess is that BaseModelFormSet.save_existing_objects() is skipping the form because form.has_changed() is False.

Yes the problem is likely related to the fact that the form has not been changed, though I think it is the has_changed in save_new that is causing the issue here. Thing is, if nothing has changed, how is the admin code supposed to figure out that a new item should be created? I don't believe it is always the case that you'd want admin creating objects with all defaults (actually I'm pretty sure there was once a bug because admin did that). I am not sure that the admin interface, as it currently exists, supports what is being asked for here. There is currently no explicit "add this item" checkbox (as there is for delete), thus the admin has to figure out the right thing to do. It does that now by seeing if anything has changed since the form was presented to the user. If yes, then an object is added. If no, then no new object is created. I don't quite see how to support this use case, and also the case where you don't want all-default objects created (which is also valid), without a pretty significant change in the admin interface here.

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