Opened 15 years ago
Closed 13 years ago
#11807 closed Bug (duplicate)
Admin inlines onetoone related object not saved
Reported by: | 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 )
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
Attachments (1)
Change History (6)
follow-up: 2 comment:1 by , 15 years ago
Component: | Uncategorized → django.contrib.admin |
---|---|
Patch needs improvement: | set |
by , 15 years ago
Attachment: | django-2009-08-31-admin-onetoone-pk-inline-test.diff added |
---|
Patch that adds a regression test for this issue.
comment:2 by , 15 years ago
Description: | modified (diff) |
---|---|
Triage Stage: | Unreviewed → Design 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 becauseform.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.
comment:3 by , 15 years ago
Sry for the initial formatting. What about leaving that decision to the app designer/developer by introducing a boolean flag for it? Default behaviour would be the current one - else save it as new object. Extending a model over several models isnt unusual, especially if you are going to remove normalization on a db scheme due to performance issues.
comment:4 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:5 by , 13 years ago
Easy pickings: | unset |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
I'm going to close this one as a dupe of #14832 on the basis that it's been accepted and that it has a slightly clearer description.
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 thatBaseModelFormSet.save_existing_objects()
is skipping the form becauseform.has_changed()
is False.