#14938 closed (fixed)
"Save as" does not save entries added with a Inline
Reported by: | rax | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | 1.2-beta |
Severity: | Keywords: | save-as | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
What steps will reproduce the problem?
- go to the admin change form of an instance of a model class with both the "save as" feature enabled, and a TabularInline for relate items.
- change the original instance
- add a new related instance using the TabularInline
What is the expected output? What do you see instead?
A new instance should be created, a copy of all the related instances should be created and a new instance for any item added in the TabularInline should be created.
Instead the original item is created, all the pre-existing instances are copied but the new ones are not created.
Note: deleting an entry works as expected is just the add that "fails" by creating the new instance without adding the new related items.
Additional information
django version: 1.2.3
locale: it-IT
this may also be related to #4045
Attachments (1)
Change History (12)
by , 14 years ago
Attachment: | 14938_patch.txt added |
---|
comment:1 by , 14 years ago
Has patch: | set |
---|---|
Needs tests: | set |
The "save as" button in the admin change form simply redirects to the add_view with the only difference that the "save_as_new" parameter is passed to the formset:
formset = FormSet(data=request.POST, files=request.FILES, instance=new_object, save_as_new=request.POST.has_key("_saveasnew"), prefix=prefix, queryset=inline.queryset(request))
Where "FormSet" are instances of "BaseInlineFormSet"
It's a problem in the BaseInlineFormSet class. See the attached patch.
comment:2 by , 14 years ago
milestone: | → 1.3 |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
Yes, I could verify this issue. Here's a simple test case:
Models:
from django.db import models class Foo(models.Model): name = models.CharField(max_length=30) class Bar(models.Model): parent = models.ForeignKey(Foo) title = models.CharField(max_length=30)
Admin:
from django.contrib import admin from .models import Foo, Bar class BarInline(admin.StackedInline): model = Bar class FooAdmin(admin.ModelAdmin): inlines = (BarInline,) save_as = True admin.site.register(Foo, FooAdmin)
New inlines added before clicking "Save as new" get lost.
I really doubt your patch is the way to go , though.
comment:5 by , 14 years ago
Keywords: | blocker regression added |
---|
comment:6 by , 14 years ago
Summary: | "Save as" does not save entries added with a TabularInline → "Save as" does not save entries added with a Inline |
---|
comment:7 by , 14 years ago
Component: | django.contrib.admin → Forms |
---|
Actually, the modification proposed by the OP doesn't seem wrong. Simply removing the BaseInlineFormSet implementation of the total_form_count()
method and so leaving to defer to the implementation in BaseFormSet makes the newly filled inline formsets to get validated and (once corrected if they didn't validate) saved associated with the new cloned parent model instance
That if self.save_as_new :
condition was added when these methods (total_form_count()
and initial_form_count()
) were introduced back in r10190 ~two years ago.
Joseph Kocherhans expressed on IRC it is possible this might be an implementation bug.
Changing component because this doesn't seem to be a admin-specific problem.
comment:8 by , 14 years ago
Keywords: | blocker regression removed |
---|
Not sure why I marked this blocker, regression; on inspection, it doesn't appear to be either. It's been a problem since at least 1.1.X, and it doesn't involve data loss (there's lost data on entry, but nothing destructive happens to existing data)
comment:9 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Patch fixing the issue