Order matters when creating custom model managers in admin interface.

[FunkyELF]

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.

[sebastian.hillig]

A nice way should exist to specify your default manager than to change an internal variable (._default_manager). Or at least it should be documented that order matters.

[jjackson]

The book Practical Django Projects has this problem with its weblog application.

[FunkyELF]

Replying to jjackson:

The book Practical Django Projects has this problem with its weblog application.

That is where I got it from. Nice to see people checking for bugs before submitting new ones.
That book has several problems that I have ran in to so far. One of the problems being that it didn't give a set of versions for all of the plugins it uses or even django itself. Personally I'd rather get those specific versions, fly through the book, then start using SVN releases. The book tries to gradually introduce stuff to you which is no good when you have to read in depth about the admin interface changes before you even know what an admin interface is.
Another problem in the book is that it says you can get downloads from the apress web site but when you go there, theres no downloads. What a pain in the butt hand typing all that HTML. I submitted errata about that but still no downloads....does anybody look at that?

[jjackson]

See also ticket 7510 where there are patch(es) to handle this problem. (​http://code.djangoproject.com/ticket/7510)

[mrts]

Actually, you can achieve whatever you need with ModelAdmin.queryset. Closing as a duplicate of #10712 and #10761.