Code

Opened 6 years ago

Closed 5 years ago

#8114 closed (duplicate)

Order matters when creating custom model managers in admin interface.

Reported by: FunkyELF Owned by: nobody
Component: contrib.admin Version: master
Severity: Keywords: admin model manager
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (0)

Change History (6)

comment:1 Changed 6 years ago by FunkyELF

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 6 years ago by bastih

  • Needs documentation set
  • Triage Stage changed from Unreviewed to Accepted

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.

comment:3 follow-up: Changed 6 years ago by jjackson

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

comment:4 in reply to: ↑ 3 Changed 6 years ago by 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?

comment:5 Changed 6 years ago by jjackson

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

comment:6 Changed 5 years ago by mrts

  • Resolution set to duplicate
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.