Opened 16 years ago

Closed 2 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


See 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
   ) # no need for the tedious for model in [A, B, C, D]:

Change History (26)

comment:1 by Jacob, 16 years ago

milestone: 1.0post-1.0
Triage Stage: UnreviewedSomeday/Maybe

comment:2 by mrts, 16 years ago

app = settings.INSTALLED_APPS[0] is actually useless in the example.

comment:3 by Martin Mahner, 16 years ago

Cc: Martin Mahner added

comment:4 by sorl, 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 sorl, 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 anonymous, 16 years ago

Cc: ega641@… added

comment:7 by sorl, 15 years ago

What do you think of something like an optional layout?: = (
    (_("don't touch this stuff"), {
        'models': ('',
    (_('users & groups'), {
        'models': ('django.contrib.auth.models',
            'User', 'Group'
    (_('pages & news'), {
        'models': ('',

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 Jannis Leidel, 15 years ago

Cc: Jannis Leidel added

comment:9 by Andy Baker, 15 years ago

Cc: andy@… added

comment:10 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:11 by phaesler, 15 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 '' and 'spam.eggs.myapp' are both in the INSTALLED_APPS list, and both have an; then admin displays them both as a single merged 'myapp' application.

comment:12 by Russell Keith-Magee, 14 years ago

#11895 proposed a similar idea, and provided a patch (which could also be implemented using subclassing).

comment:13 by sampablokuper, 14 years ago

Cc: sam.kuper@… added

Added CC.

comment:14 by anonymous, 13 years ago

Cc: sehmaschine@… added

comment:15 by Luke Plant, 13 years ago

Severity: Normal
Type: New feature

comment:16 by Ben Davis, 13 years ago

Cc: Ben Davis added
Easy pickings: unset
UI/UX: unset

comment:17 by rh0dium, 12 years ago

Cc: rh0dium added

comment:18 by Sebastian Goll, 12 years ago

Cc: sebastian.goll@… added

comment:19 by Aymeric Augustin, 11 years ago

Resolution: duplicate
Status: newclosed
Triage Stage: Someday/MaybeAccepted

This is #3591 — also known as the 'app-loading' branch.

comment:20 by Aymeric Augustin, 10 years ago

Resolution: duplicate
Status: closednew

Mmm, in fact this was specifically split from app-loading. Sorry.

comment:21 by Evgeny Tatarintsev, 4 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 Roman, 2 years ago

To move things a little bit forward I have prepared a pull request based on this comment

comment:23 by Mariusz Felisiak, 2 years ago

Has patch: set
Needs documentation: set
Owner: changed from nobody to Roman
Status: newassigned

comment:24 by Mariusz Felisiak, 2 years ago

Needs documentation: unset
Triage Stage: AcceptedReady for checkin

comment:25 by Mariusz Felisiak <felisiak.mariusz@…>, 2 years ago

In d44951b3:

Refs #7497 -- Added assertion for the default order of models in AdminSite.app_index().

comment:26 by Mariusz Felisiak <felisiak.mariusz@…>, 2 years ago

Resolution: fixed
Status: assignedclosed

In 2bee0b4:

Fixed #7497 -- Allowed overriding the order of apps and models in admin.

Note: See TracTickets for help on using tickets.
Back to Top