Admin model manager

[troy.simpson@…]

From: ​http://www.djangoproject.com/documentation/model-api/
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).

[troy.simpson@…]

Update:
I found a similar issue from new-forms

#4342

[James Bennett]

Duplicate of #2644.