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
8114	Order matters when creating custom model managers in admin interface.	FunkyELF	nobody	"I have created a model called entry.

I created a custom manager for it...

{{{
class LiveEntryManager(models.Manager):
    def get_query_set(self):
        return super(LiveEntryManager, self).get_query_set().filter(status=self.model.LIVE_STATUS)
}}}


Within the Entry model if I have the following two lines of code, the admin interface will allow me to edit all entries with any status.


{{{
objects = models.Manager()
live = LiveEntryManager()
}}}


However, if I have the lines of code in reverse order...


{{{
live = LiveEntryManager()
objects = models.Manager()
}}}


The admin interface only shows entries with status LIVE_STATUS.

The documentation says that the first manager created in a model is treated as a default manager.  But then it explicitly says that the admin interface was not one of those parts.
From http://www.djangoproject.com/documentation/model-api/ ...
If you use custom Manager objects, take note that the first Manager Django encounters (in the order in which they’re defined in the model) has a special status. Django interprets this first Manager defined in a class as the “default” Manager, and several parts of Django (though not the admin application) will use that Manager exclusively for that model. As a result, it’s often a good idea to be careful in your choice of default manager, in order to avoid a situation where overriding of get_query_set() results in an inability to retrieve objects you’d like to work with.

This was using SVN from a few days ago.  I did not see anything about this in the backward incompatible changes but I also didn't test with an older version of django (because of all the backward incompatible changes it wouldn't work with an older version).

Seems like the documentation is out of sync with the code since it explicitly says that the admin interface isn't affected by which one was created first.
The admin interface should by default use a manger that returns everything; even if a customer manager is in place and one isn't explicitly defined using ""objects = models.Manager()"".
If you want the admin interface to use a manager that doesn't return everything you should override it by extending admin.ModelAdmin or something.

Again, the admin interface should ignore all custom defined model managers and always return all objects.
Sorry about the links to the wiki, don't know why they are there or how to get rid of them, they were created automatically."		closed	contrib.admin	dev		duplicate	admin model manager		Accepted	0	1	0	0	0	0