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
9602	Add admin.site._registry manipulation methods	Rob Hudson	Mariusz Felisiak	"This is a feature request...

Currently, one can unregister a model from the admin and register it again with a new ModelAdmin.  The problem I'm anticipating is when 2 or more apps want to add ModelAdmin options to a Model and the last one wins.

Not to point out a specific 3rd party app, but this is an easily contrived example... If I have my own apps and one of them unregisters the User model's ModelAdmin and registers its own that, say, adds the `is_superuser` to the list_display.  Then if I add the django-openid app that (currently) also unregisters the User model's ModelAdmin and registers its own that adds an inline to a ManyToManyField for the OpenID associations tied to that user.  If django-openid is after my app in the INSTALLED_APPS list, I lose my list_display override.  And if my app is after the django-openid app, I lose the OpenID associations inlines.  (See: http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py)

It's possible currently to write the unregistration/registration such that this doesn't happen, but it relies on pulling the ModelAdmin out of the ""private"" _registry dictionary in the admin.site class.  For example:

{{{
useradmin = admin.site._registry.get(User, None)
if useradmin:
    useradmin.list_display = useradmin.list_display + ('is_superuser',)
else:
    class MyUserAdmin(AuthUserAdmin):
        list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff', 'is_superuser')
    admin.site.register(User, MyUserAdmin)
}}}

I can think of a few ways of fixing this, from least involved to more involved:

1. At the very least I think it would be nice if the internal `_registry` dictionary didn't have the prepended underscore to signify that it is a private variable not to be touched, so one doesn't feel dirty doing something like this.

2. I think it would be a bit cleaner if there were methods to lookup, get, and update this dict and keep it as a private dict.  For example, something like `admin.site.get_model_admin(User)`?

3. Along with 2, provide methods to update common ModelAdmin options, like `list_display`.  This one is definitely venturing into debatable area, but something like `useradmin.list_display.add('is_superuser')` takes much away from this feeling so ""monkey patchy""."	New feature	closed	contrib.admin	dev	Normal	fixed	register modeladmin	rob@…	Accepted	1	0	0	0	0	0