Django

Code

Ticket #7497 (new)

Opened 2 years ago

Last modified 6 months ago

AppAdmin class for customizing app listing in admin index

Reported by: mrts Assigned to: nobody
Milestone: Component: django.contrib.admin
Version: SVN Keywords:
Cc: bartTC, ega641@mail.ru, jezdez, andy@andybak.net, sam.kuper@uclmail.net Triage Stage: Someday/Maybe
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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)

Attachments

Change History

06/18/08 13:08:22 changed by jacob

  • needs_better_patch changed.
  • needs_docs changed.
  • stage changed from Unreviewed to Someday/Maybe.
  • needs_tests changed.
  • milestone changed from 1.0 to post-1.0.

06/18/08 13:19:27 changed by mrts

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

06/19/08 04:42:37 changed by bartTC

  • cc set to bartTC.

08/02/08 13:04:33 changed by sorl

Can't we just add a label attribute to the ModelAdmin? class? ModelAdmin? classes with same label would group, possibly also position attribute.

08/02/08 13:23:35 changed by sorl

Im just thinking that the application grouping might not have much to do with how an administrator uses the admin tool.

08/18/08 13:01:54 changed by anonymous

  • cc changed from bartTC to bartTC, ega641@mail.ru.

09/11/08 08:07:14 changed by sorl

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

09/20/08 16:17:46 changed by jezdez

  • cc changed from bartTC, ega641@mail.ru to bartTC, ega641@mail.ru, jezdez.

01/01/09 09:01:35 changed by andybak

  • cc changed from bartTC, ega641@mail.ru, jezdez to bartTC, ega641@mail.ru, jezdez, andy@andybak.net.

02/25/09 13:51:44 changed by

  • milestone deleted.

Milestone post-1.0 deleted

05/05/09 23:40:13 changed by phaesler

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.

09/17/09 06:26:27 changed by russellm

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

09/17/09 09:19:12 changed by sampablokuper

  • cc changed from bartTC, ega641@mail.ru, jezdez, andy@andybak.net to bartTC, ega641@mail.ru, jezdez, andy@andybak.net, sam.kuper@uclmail.net.

Added CC.


Add/Change #7497 (AppAdmin class for customizing app listing in admin index)




Change Properties
Action