ModelAdmin should be able to use a non-default manager

[tom]

At the moment the change_view and delete_view methods of
ModelAdmin in django/contrib/admin/options.py both use the
default manager of the model when retrieving an instance for
change or deletion. However, there is a "queryset" method on the
same class that is used to get the list of models to display in
the changelist. This means that to remove certain instances from
the admin one has to both update the queryset method to filter
them out and then change the 3 has_*_permission methods. This
doesn't seem very DRY to me.

I propose changing the change_view, delete_view and history_view methods so
that they simply use the queryset returned by the queryset method
instead of the default managers. This means that an filters put
on the queryset by the queryset method are honored and there is
thus only one place to change when you want to remove a subset of
objects from consideration.

This seems like a useful change to make to me and I can't see any
problems it would create but maybe I'm missing something...

[jfw]

I also found a need to have change_view use a different queryset than the _default_manager's one. Before seeing the above patch, I had created my own. I think this one (attached) adds a little more flexibility, as it lets you override the manager used in all of the admin site. You can still override the queryset function, but it might be less necessary to do so.

[Alex Gaynor]

Patch with tests

[jjackson]

Here's another patch to handle this problem. I used this to fix the problem in Practical Django Projects.

After the patch has been applied, you can then use in your model an order such as

class Entry(models.Model):
    live = LiveEntryManager()
    objects = models.Manager()

and then in your admin.py use

class EntryAdmin(admin.ModelAdmin):
    prepopulated_fields = {'slug': ('title',)}
    model_admin_manager = Entry.objects

to set the manager to be used by the admin application for the Entry class. In this case, we wanted to see only the live entries on the website, but to see all the entries in admin app. Otherwise, after setting a Entry to "draft", you would never be able to edit it again.

[jjackson]

Patch as of rev 8861 or Django 1.0.

[Torsten Rehn]

I changed the summary as I think the ability to use a non-default manager is more important and implies the original request to be honored.

I also want to point out that the documentation on this topic is incorrect (at least as I read it):

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.

from docs/topics/db/managers.txt:170-173 or ​online docs

As I interpret this, the admin is supposed to always use a "bare" Manager(), not the default manager, as it is currently doing.

Plus, this makes it impossible to use a custom manager in related lookups, but not the admin (use_for_related_fields can only be used in the default manager, I don't really know why there is no Model.Meta.related_manager option).

[anonymous]

​Buy Cheap Coach Purses Handbags
​BUY COACH PURSE COACH ERGO SIGNATURE BIFOLD MINI WALLET

[Chris Beaven]

scel is correct that the current documentation is out of date.

brosner agrees that this is issue valid.

A small suggestion for the patch: just set model_manager = None as a ModelAdmin class attribute, then you don't have to worry about hasattr and it's a bit more of an obvious API attribute (model_admin_manager seems overly verbose - of course it's for admin ;))

[mrts]

Looks useful, tentatively pushing to 1.2.

[Jacob]

(In [10314]) Fixed #7510: the ModelAdmin now uses self.queryset instead of the default manager. Thanks, Alex Gaynor.

[Jacob]

Milestone 1.2 deleted