id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
7497	AppAdmin class for customizing app listing in admin index	mrts	Roman	"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)
}}}"	New feature	closed	contrib.admin	dev	Normal	fixed		Martin Mahner ega641@… Jannis Leidel andy@… sam.kuper@… sehmaschine@… Ben Davis rh0dium sebastian.goll@…	Ready for checkin	1	0	0	0	0	0