Opened 14 years ago
Closed 12 years ago
#16089 closed New feature (fixed)
Adding/Removing admin Inlines on the fly
Reported by: | sheep2 | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Inlines are very useful for creating/updating related objects at the same time. However, sometimes you only want to create/update one of the objects instead of both. For example, when creating a User you may not want to add the associated content in a related profile model, but want to do so later.
The current implementation defines and instantiates the inlines when a admin.ModelAdmin class is instantiated, but does not allow addition/removal of more inlines anywhere(or anytime) else.
I propose two functions register_inline_instance() and unregister_inline_instance() that allow inlines to be added and removed from a model on the fly.
Example usage:
class UserAdmin(admin.ModelAdmin): inlines = [StudentInline,] ... def add_view(self, request, form_url='', extra_context=None): self.unregister_inline_instance(StudentInline) return super(UserAdmin, self).add_view(request, form_url, extra_context) def change_view(self, request, form_url='', extra_context=None): self.register_inline_instance(StudentInline) return super(UserAdmin, self).change_view(request, form_url, extra_context) ...
Attachments (1)
Change History (7)
by , 14 years ago
Attachment: | inlines.diff added |
---|
follow-up: 2 comment:1 by , 14 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Design decision needed |
Thanks for the suggestion. I do see how this could be useful in some cases. It needs further design discussion for the implementation, though.
comment:2 by , 13 years ago
Replying to julien:
Thanks for the suggestion. I do see how this could be useful in some cases. It needs further design discussion for the implementation, though.
Fair enough, do you think there are design problems this fix would cause?
comment:3 by , 13 years ago
What doesn't feel right with this proposal is that it is explicitly about *undoing* things. There are at least two problems with that: a) It is too tightly coupled with the admin's internal implementation and therefore it is likely to diminish the admin's flexibility in the long term; and b) Instead of undoing something that has been done, it is best to not do it in the first place (i.e. don't register an inline only to unregister it later).
The usual pattern in the admin is to provide hooks to *override* behaviours, not *undo* them. Currently inlines can only be registered declaratively with ModelAdmin.inlines
, so to allow the flexibility that you're after it would be best to follow the usual pattern and wrap the declarative registration with a hook that can be overridden. See for example ModelAdmin.get_prepopulated_fields()
or ModelAdmin.get_readonly_fields()
.
Inlines are also currently registered very early in the process, when the ModelAdmin
class is instantiated. To make this work you would also have to move that registration later in the process (e.g. in the views) so that inlines can be selectively registered based on the request.
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I think this was fixed in c2e19e26bc33d34eff57079bd1a6838ff64d9e81, some example code (should work, untested):
def get_inline_instances(self, request, obj=None): if obj is None: return [] return super(Bla, self).get_inline_instances(request, obj)
If there are still issues please reopen the ticket and provide more information.
git style diff created by hg