Opened 16 years ago
Closed 3 years ago
#7497 closed New feature (fixed)
AppAdmin class for customizing app listing in admin index
Reported by: | mrts | Owned by: | Roman |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Martin Mahner, ega641@…, Jannis Leidel, andy@…, sam.kuper@…, sehmaschine@…, Ben Davis, rh0dium, sebastian.goll@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
See http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling for details.
This supplements the app
directive.
As discussed with brosner
and jkocherhans
in #django-dev:
<brosner> it looks reasonable, but haven't spent much time thinking about it <jkocherhans> mrts: I think this is clearly backwards incompatible with the current nfa api and has to go in pre 1.0 if it goes in at all <jkocherhans> I'm a big -1 on the order attribute and -0 on models (maybe just a different syntax), but the other stuff seems reasonable <mrts> jkocherhans: what's wrong with ordering? <jkocherhans> it just feels like the wrong place to specify it <jkocherhans> it's a global issue, and an issue any particular app should handle <mrts> my use case: I have a lot of functionality exposed to somewhat dumb users <mrts> and they have trouble finding the right bits in the admin interface ordering is only used in context of admin index I would like to put the important apps to top and collapse the rest <jkocherhans> exactly. what should 3rd party apps put there? therein lies my objection. <mrts> well, I'd say decouple admin from models (as nfa already does) and don't specify any admin options at all -- users are free to customize things with AppAdmin <jkocherhans> I guess not if using a AppAdmin class is optional. I was originally thinking it would replace model registration with an admin site. <mrts> jkocherhans: yeah, that's what I kinda meant... it looks more coherent this way jkocherhans: and it may solve some of the issues register() currently has <jkocherhans> mrts: I'm gonna have to let it sit for awhile. I'm trying to think of what else an AdminApp class would do besides being a coathanger for a few attributes, nothing is coming to mind. <mrts> jkocherhans: but jezdez has a point -- it would also provide easy bridging for app instances
Example syntax follows.
class BarModelAdmin(admin.ModelAdmin): description = 'A bar is a bar is a bar' ... class FooAppAdmin(admin.AppAdmin): app = settings.INSTALLED_APPS[0] name = "Foo" # overrides app().name description = "An application that does foo" style = {'classes' : ('collapse',)} order = 1 models = ( # model order in this list determines their display order in app block (BarModel, BarModelAdmin), (BazModel, None), # use default ModelAdmin, don't show description ) admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model)
Change History (26)
comment:1 by , 16 years ago
milestone: | 1.0 → post-1.0 |
---|---|
Triage Stage: | Unreviewed → Someday/Maybe |
comment:2 by , 16 years ago
comment:3 by , 16 years ago
Cc: | added |
---|
comment:4 by , 16 years ago
Can't we just add a label attribute to the ModelAdmin class? ModelAdmin classes with same label would group, possibly also position attribute.
comment:5 by , 16 years ago
Im just thinking that the application grouping might not have much to do with how an administrator uses the admin tool.
comment:6 by , 16 years ago
Cc: | added |
---|
comment:7 by , 16 years ago
What do you think of something like an optional layout?:
admin.site.layout = ( (_("don't touch this stuff"), { 'models': ('', 'django.contrib.sites.models.Site', ) }), (_('users & groups'), { 'models': ('django.contrib.auth.models', 'User', 'Group' ) }), (_('pages & news'), { 'models': ('', 'example_project.pages.models.Page', 'example_project.news.models.News', ) }), )
Also adding a description attribute to ModelAdmin.
You can see and read further on this idea and look at the implementation in my project sorl-curator
comment:8 by , 16 years ago
Cc: | added |
---|
comment:9 by , 16 years ago
Cc: | added |
---|
comment:11 by , 16 years ago
A somewhat related point - if you have two applications with the same basename in the one project, the admin application displays them as if they were merged into a single application with that name.
E.g. If 'foo.bar.myapp' and 'spam.eggs.myapp' are both in the INSTALLED_APPS list, and both have an admin.py; then admin displays them both as a single merged 'myapp' application.
comment:12 by , 15 years ago
#11895 proposed a similar idea, and provided a patch (which could also be implemented using subclassing).
comment:14 by , 14 years ago
Cc: | added |
---|
comment:15 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:16 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
UI/UX: | unset |
comment:17 by , 13 years ago
Cc: | added |
---|
comment:18 by , 13 years ago
Cc: | added |
---|
comment:19 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Triage Stage: | Someday/Maybe → Accepted |
This is #3591 — also known as the 'app-loading' branch.
comment:20 by , 11 years ago
Resolution: | duplicate |
---|---|
Status: | closed → new |
Mmm, in fact this was specifically split from app-loading. Sorry.
comment:21 by , 5 years ago
Hi, I implemented apps ordering via "position" attribute in AppConfig class
class TestConfig(AppConfig): name = 'test' verbose_name = 'Test App' position = 0
Apps orders by it's "position" and then by "verbose_name", no backwards incompatible, if position not set just ordering by name.
If it's actual I can do pull request.
comment:22 by , 3 years ago
To move things a little bit forward I have prepared a pull request based on this comment
https://code.djangoproject.com/ticket/25671#comment:11
comment:23 by , 3 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Owner: | changed from | to
Status: | new → assigned |
comment:24 by , 3 years ago
Needs documentation: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
app = settings.INSTALLED_APPS[0]
is actually useless in the example.