Opened 14 years ago
Last modified 20 months ago
#14832 new Bug
Impossible to create inline objects if form validates but is unchanged
Reported by: | Julien Phalip | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.4 |
Severity: | Normal | Keywords: | sprintdec2010 |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description
Here's a simple test case:
Models:
from django.db import models class Account(models.Model): name = models.CharField(max_length=100) class Expense(models.Model): account = models.ForeignKey(Account) amount = models. IntegerField(default=100, blank=True, null=True) memo = models.CharField(max_length=100, blank=True)
Admin:
from django.contrib import admin from .models import Account, Expense class ExpenseInlineAdmin(admin.TabularInline): model = Expense class AccountAdmin(admin.ModelAdmin): inlines = [ExpenseInlineAdmin] admin.site.register(Account, AccountAdmin)
Here there is no way to create an expense object with the amount 100 and no memo. This is because Django compares the submitted values with the initial ones, and takes a (big) guess that the user wants to create an object only because she has *modified* one of the values. If the user is happy with the default values and presses 'save', then the expense object won't get created.
I've discussed this at length with DrMeers and russellm during the Dec2010 sprint. I am conscious that there is no straight forward solution to this, and that this approach was designed prior the inclusion of jquery and also to allow people without javascript to use inlines. However it seems that this system is either flawed by design, or confusing to say the least (as people rely on this behaviour and expect things to work the way they really shouldn't, i.e. #14095).
It feels that some user interface design work needs to be done to make things more explicit and intuitive. Opening this ticket to keep track of this request, as I expect some design discussions need to happen on the mailing list in parallel.
Change History (10)
comment:1 by , 14 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
#15174 was closed as dupe (different use case but essentially the same problem).
comment:3 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:4 by , 13 years ago
Easy pickings: | unset |
---|
#11807 reported the same issue, contains a detailed analysis by kmtracey and has a test case.
comment:5 by , 13 years ago
UI/UX: | set |
---|
comment:6 by , 11 years ago
Version: | 1.2 → 1.4 |
---|
comment:8 by , 20 months ago
After about 14 years after the first report (#11807) this issue is still present.
I belive that this may be addressed with a change in the APIs in inline admins and model-formset.
But first it must be defined a logic to handle this operation:
- one-to-one inline is easy, it should be created
- many-to-one inline is not so easy, since it depends on the application context
- many-to-many inline should follow the same criteria as many-to-one
For these reasons I propose the following mechanism:
- add a new method to
InlineModelAdmin
which controls over the "create-if-empty" mechanism, which should receive as params the main object and count of already handled "empty" forms and which should return a boolean (indicating if the empty form shall be created or not) - add a new optional attribute to
BaseInlineFormSet
which is going to hold a method like that described above - override the
save_new_objects
inBaseInlineFormSet
to handle the abovementioned attribute and thus proceeding with the creation of "empty" forms when confirmed.
comment:10 by , 20 months ago
Replying to gustutu:
I also need this feature :)
This kind of comments are not helpful. Please feel-free to prepare a patch if you want it fixed in Django.
This is a messy problem, and needs some UX love to work out the right solution.