Admin model manager
|Reported by:||Owned by:||Adrian Holovaty|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
If you use custom Manager objects, take note that the first Manager Django encounters (in order by which they’re defined in the model) has a special status. Django interprets the first Manager defined in a class as the “default” Manager. Certain operations — such as Django’s admin site — use the default Manager to obtain lists of objects, so it’s generally a good idea for the first Manager to be relatively unfiltered. In the last example, the people Manager is defined first — so it’s the default Manager.
Reading the docs, this would tell me if I override the Manager of a class, the first Manager defined will be the "default Manager". This is absolutely correct. However, Django's admin site does not correctly use the default Manager of a class. It uses the undocumented "manager" as a result of the changelist implementation.
So, if you wish to intentionally filter the admin results, this will NOT work:
class filterManager(models.Manager): def get_query_set(self): return super(filterManager, self).get_query_set().filter(name='troy') class Blah(models.Model): name = models.CharField(maxlength=100) objects = filterManager() class Admin: pass
This WILL work:
class filterManager(models.Manager): def get_query_set(self): return super(filterManager, self).get_query_set().filter(name='troy') class Blah(models.Model): name = models.CharField(maxlength=100) objects = filterManager() class Admin: manager = filterManager()
This "manager" in the Admin class is undocumented.
I propose one of two solutions:
1) Document this "manager", which will prevent unintentional filtering in the Admin site.
2) Change the Admin to use the object's default Manager.
I could provide some specific code changes if the decision is for 2).