Opened 7 years ago

Last modified 5 weeks ago

#8851 assigned New feature

Please add a default option to list_filter in the admin interface

Reported by: Riskable <riskable@…> Owned by: hvdklauw
Component: contrib.admin Version: master
Severity: Normal Keywords: admin, list_filter, default
Cc: carljm, trevor, rlaager@…, andy@…, wizard@…, kc9ddi, remco@…, net147, trbs@…, a@…, markus.magnuson@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


There should be a way to set a default list_filter in the admin interface. For example, if I had a model like this:

        ('N', 'No'),
        ('Y', 'Yes'),

class Host(models.Model):
        hostname = models.CharField(max_length=36, unique=True)
        decommissioned = models.CharField(max_length=1, choices=DECOM_CHOICES, default='N')
        ip_address = models.IPAddressField()
        def __unicode__(self):
                return self.hostname

class HostAdmin(admin.ModelAdmin):
        fieldsets = [
                ('Host Info', {'fields': ['hostname','decommissioned','ip_address']}),
        list_display = ('hostname', 'ip_address', 'decommissioned')
        list_filter = ('decommissioned'), HostAdmin)

I might want to make it so that by default only hosts that are not marked as decommissioned are displayed by default in the index. It would be nice if I could just pass an option to list_filter to set the a filter that is enabled by default. Perhaps something like this:

list_filter = ('decommissioned__exact=N') # Matches the URL if you click on "No" in the filter list

...or perhaps...

list_filter = ('decommissioned__default') # Have it choose the same default as specified in the model.

If there's already a simple way to do this I haven't found it and would appreciate an example.


Change History (33)

comment:1 Changed 7 years ago by mtredinnick

  • milestone 1.0 deleted
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 7 years ago by jacob

  • Triage Stage changed from Unreviewed to Accepted

Not a big fan of the syntax, but a useful feature.

comment:3 Changed 7 years ago by Riskable

The syntax doesn't matter... The feature is what matters =). If you're going to implement this you can do it however you like (and I thank you!).

comment:4 Changed 7 years ago by nitipit

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

That's a great idea to add this feature.
for now, I make a bit hack of code to set django.contrib.admin.filterspecs.RelatedFilterSpec.lookup_choices to get objects from "ModelAdmin.formfield_for_foreignkey()"

class RelatedFilterSpec(FilterSpec):
    def __init__(self, f, request, params, model, model_admin):
        super(RelatedFilterSpec, self).__init__(f, request, params, model, model_admin)
        if isinstance(f, models.ManyToManyField):
            self.lookup_title =
            self.lookup_title = f.verbose_name
        rel_name = f.rel.get_related_field().name
        self.lookup_kwarg = '%s__%s__exact' % (, rel_name)
        self.lookup_val = request.GET.get(self.lookup_kwarg, None)
#       self.lookup_choices = f.rel.get_choices(include_blank=False); >> f.rel.get_choices will return lists of object tuple
        self.lookup_choices = [] ;
        for object in model_admin.formfield_for_foreignkey(f,request).queryset :
            list = (,object.__str__()) ;

Then just use formfield_for_foreignkey() which is described in django document to filter the objects we want.

comment:5 Changed 7 years ago by kmtracey

  • Resolution fixed deleted
  • Status changed from closed to reopened

A workaround in a comment doesn't make the ticket fixed. The ticket is fixed when a change is checked into the Django source tree.

comment:6 Changed 7 years ago by carljm

  • Cc carljm added

comment:7 Changed 7 years ago by anonymous

  • Cc trevor added

comment:8 Changed 7 years ago by anonymous

  • Cc rlaager@… added

comment:9 Changed 6 years ago by anonymous

  • Cc andy@… added

comment:10 Changed 6 years ago by wizard@…

  • Cc wizard@… added

Is this something that just needs committing?

comment:11 Changed 6 years ago by kc9ddi

  • Cc kc9ddi added

comment:12 Changed 5 years ago by shanx

  • Cc remco@… added

comment:13 Changed 5 years ago by lukeplant

  • Severity set to Normal
  • Type set to New feature

comment:14 Changed 5 years ago by mofle

  • Easy pickings unset

This would be very useful. Hoping for this in 1.4.

There is a ugly workaround on StackOverflow, but this does not show the default filter in the filterbar.

comment:15 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:16 Changed 3 years ago by net147

  • Cc net147 added

comment:17 Changed 3 years ago by charettes

I think you can achieve this in 1.4+ by subclassing django.contrib.admin.ChoicesFieldListFilter.

comment:18 Changed 3 years ago by aaugustin

  • Status changed from reopened to new

comment:19 Changed 3 years ago by oinopion

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

This feature has been already introduced in Django, unfortunately, I don't know when. Basically, subclass SimpleListFilter and override two methods lookups and queryset. You can read about it in ModelAdmin.list_filter docs

I'm closing this ticket as fixed, as described feature is in my opinion what you were looking for. If you feel it's not what you need, please reopen with detailed description what should be changed.

comment:20 Changed 2 years ago by schrinaw@…

  • Resolution fixed deleted
  • Status changed from closed to new

I would argue that this is not fixed. I believe I have the same issue as the OP - I want to choose which of the available filter options should be selected by default. I don't want to customize the filtering behavior by subclassing SimpleListFilter. The desired behavior is that when I go to admin changelist url, it is *as if I had already chosen one of the filtering options*. I don't want to change the behavior of the filtering options. I just want one (the defined default) to be pre-selected.

comment:21 Changed 18 months ago by trbs

  • Cc trbs@… added

comment:22 Changed 5 months ago by ckirby

  • Owner changed from nobody to ckirby
  • Status changed from new to assigned

comment:23 Changed 5 months ago by ckirby

  • Owner ckirby deleted
  • Status changed from assigned to new

comment:24 Changed 3 months ago by hvdklauw

  • Owner set to hvdklauw
  • Status changed from new to assigned

Working on this during duth sprints

comment:25 Changed 3 months ago by hvdklauw

  • Has patch set

comment:26 Changed 3 months ago by avorio

  • Cc a@… added

comment:27 Changed 3 months ago by avorio

I'm willing to test this out once a patch has been committed.

Implemented simply, as originally described, this would be a very useful feature indeed.

comment:28 Changed 3 months ago by timgraham

While testing after commit is certainly helpful, if you can give feedback on and/or test the pull request before it's committed, that's even more helpful.

comment:29 Changed 3 months ago by hvdklauw

  • Patch needs improvement set

Just did some testing as well, and the filters selected value does not work correctly with the defaults. Working on a fix.

comment:30 Changed 3 months ago by hvdklauw

  • Patch needs improvement unset

Totally forgot to update the ticket, it's all done and ready now.

Should note that the fix was to actually NOT use request.GET at all in the filters, but the passed in params dictionary which contains the by the ChangeList preprocessed data.

I think this was always meant to be like this, but was never caught because filters are always only tested through the changelist.

Not sure if we want to slow down the build process even more with more detailed unittests.

Last edited 3 months ago by hvdklauw (previous) (diff)

comment:31 Changed 2 months ago by giuliettamasina

  • Cc markus.magnuson@… added

comment:32 Changed 5 weeks ago by xblitz

+1 and bump, will this be included in 1.10 ?

comment:33 Changed 5 weeks ago by timgraham

You can help by reviewing the patch using the PatchReviewChecklist and marking the ticket "ready for checkin" when all looks good.

Note: See TracTickets for help on using tickets.
Back to Top