Support for lookup separator with list_filter admin option

Patch for list_filter options

Improved patch

Hmm not sure how I didn't notice before, but this breaks the model validation in django.core.management:

for fn in opts.admin.list_display:
    try:
        f = opts.get_field(fn)
    except models.FieldDoesNotExist:
        if not hasattr(cls, fn):
            e.add(opts, '"admin.list_display" refers to %r, which isn\'t an attribute, method or property.' % fn)
    else:
        if isinstance(f, models.ManyToManyField):
            e.add(opts, '"admin.list_display" doesn\'t support ManyToManyFields (%r).' % fn)

Of course, it shouldn't be hard to fix - but is it worth it? This type of filtering is very useful for my particular apps but if it's not considered common enough for the core there's no point fixing the validation.

I think it's worth getting this right. You probably aren't the only person wanting this functionality.

A couple of comments on the patch:

1. please create the diff from the top of the Django source tree. I had to guess a lot to work out that it was to be applied to django/contrib/admin/views/main.py (which I think is right). Having the full path from the tree root to the patched file is helpful.
2. If the FakeForeignKey class has any visibility outside of that function (which I'm not sure about), it shouldn't be declared inside the function. In fact, I'm not really thrilled with declaring it inside the function in the first place, so probably best to move it out to the top-level of the file. I realise you are trying to avoid namespace pollution, but it's not worth the sacrifice of clarity to me.

1. Oops, sorry about the diff - yes that's the correct file.
2. FakeForeignKey is a wrapper around the ForeignKey field so that the RelatedFilterSpec will work across the foreign keys. Perhaps it could have a better name. It is only instantiated inside get_filters(), but RelatedFilterSpec will have access to it.. so I'll move it to the top-level of the file like you have suggested.

Will update the patch shortly when I have some time, Cheers.

Improved patch per suggestions

Works great thanks Nick. This was bugging me just the other day.

This is exactly what I need. I'm going to apply this and try it out.

Updated diff for new management module

I attached an alternative patch for newforms-admin branch... It can deal with __ paths not just for RelatedFields but for any fields. It will traverse the path, return the last field in the chain and supply additional parameter field_path that is used for filtering the results.

With this you can filter for example by a DateField stored on a related model.

Also see #5833 for a way to enable users to register their own filter.

This is a feature enhancement and not critical to the merge of newforms-admin into trunk. Tagging with nfa-someday. I would like to see this functionality get in. After newforms-admin gets merged I will look into this more and examine the patches present.

I checked and applied 3400-against-7875.patch, all tests passed.

Just wrote small app for testing this. I don't want to write tests. models.py:

from django.conf import settings
from django.db import models
from django.contrib import admin

class Town(models.Model):
    name = models.CharField(max_length=64)
    
    def __unicode__(self):
        return self.name

class House(models.Model):
    town = models.ForeignKey(Town)

    def __unicode__(self):
        return self.town.name

class Room(models.Model):
    house = models.ForeignKey(House)

    def __unicode__(self):
        return self.house.town.name

class Booking(models.Model):
    room = models.ForeignKey(Room)

    def __unicode__(self):
        return self.room.house.town.name
    
class BookingOpts(admin.ModelAdmin):
    list_filter = ('room__house__town',)
    raw_id_admin = ('room', )

admin.site.register(Town)
admin.site.register(House)
admin.site.register(Room)
admin.site.register(Booking, BookingOpts)

Works fine.

I've applied 3400-against-7875.patch to today svn django-trunk and I get the following error:

Error while importing URLconf 'myapp.urls': ProjectAdmin.list_filter[8] refers to field technology__programing_languages that is missing from model Project.

The models are:

class Project(models.Model):

technology = models.ForeignKey("ProjectTechnology?", verbose_name=_('project technology'),unique=True, null=True, blank=True, editable=False, related_name="technology") ...

class ProjectTechnology?(models.Model):

programing_languages = models.ManyToManyField?(ProgramingLanguage?, null=True, blank=True) ...

class ProgramingLanguage?(models.Model):

name = models.CharField?(_('name'), max_length=200) ...

I'm almost a newbie, what it could be?

Thanks.

Thanks, 3400-against-8363.patch solves the problem.

Should it be possible now to show attributes (or foreignkeys) of other model B that have a foreignkey to model A in model A list_filter?, how?

If I should make my question to other sites, don't complaint to tell me.

Thanks in advance.

Path 3400-against-8363.patch does not run against revision 9285.

Is there a way to use lookup separator without patch django?

Does this patch include a way to add sort_by as well?

This needs a sort_by option as well:

class Town(models.Model):
    name = models.CharField()

class House(models.Model):
    town = models.ForeignKey(Town)

class Room(models.Model):
    house = models.ForeignKey(House)

class Booking(models.Model):
    room = models.ForeignKey(Room, raw_id_admin=True)
    
    class Admin:
        sort_by = ('room__house__town',)

Quick update for trunk [9646]. Works wih 1.0.2 too

Any improvements needed for this patch?

Is there any chance this can make it in 1.1.?

Tentatively targeting for 1.2.

See also #10743.

patch against 10680 with tests and doc

I added patch against newest django trunk version.

main repo lives in http://github.com/HonzaKral/django/tree/ticket3400

new patch with init and some more data in tests

I feel stupid posting this, but are we sure it works with related_of_related as in the example above?

Using :

from django.db import models
class Town(models.Model):
    name = models.CharField(max_length=50)

class House(models.Model):
    town = models.ForeignKey(Town)

class Room(models.Model):
    house = models.ForeignKey(House)

class Booking(models.Model):
    room = models.ForeignKey(Room)

and

from django.contrib import  admin
from content.models import *

class BookingAdmin(admin.ModelAdmin):
    list_filter = ('room__house__town',)
    pass

admin.site.register(Booking,BookingAdmin)
admin.site.register(Town)
admin.site.register(Room)
admin.site.register(House)

I get a exception in /django/contrib/admin/views/main.py circa line 85

                if '__' in filter_name:
                    f = None
                    model = self.model
                    path = filter_name.split('__')
                    for field_name in path[:-1]:
                        f = model._meta.get_field(field_name)
                        model = f.rel.to
                        f = model._meta.get_field(path[-1]) # !!!! Exception
                        spec = FilterSpec.create(f, request, self.params, model, self.model_admin, field_path=filter_name)
                else:
                    f = lookup_opts.get_field(filter_name)
                    spec = FilterSpec.create(f, request, self.params, self.model, self.model_admin)

as it tries to get a field for path[2] (town) on model path[0] (room) on the first iteration.

I get that problem using the patch 3400-against-9646.patch, which patched all right against 1.0.2-final. That bit code looks identical on subsequent patches, though.

solved it by

                for field_name in path[:-1]:
                        f = model._meta.get_field(field_name)
                        model = f.rel.to
                        f = model._meta.get_field(path[path.index(field_name)+1])

doesn't look very robust but works so far.. Needs more testing, I guess

Working and little bit better solution - not creating intermediary FilterSpec?(s):

                    for field_index in xrange(len(path)-1):
                        f = model._meta.get_field(path[field_index])
                        model = f.rel.to
                        f = model._meta.get_field(path[field_index+1])
                    spec = FilterSpec.create(f, request, self.params, model, self.model_admin, field_path=filter_name)

Patch currently does not work with reverse relationships. For example:

class Target(models.Model):
    name = CharField(max_length=200)

class Survey(models.Model):
    target = models.OneToOneField(Target)
    source = models.ForeignKey(SurveySource)

class TargetAdmin(admin.ModelAdmin):
    list_filter = ['survey__source']
    

My hunch is that this only breaks in the validation code -- I'm investigating right now if that will fix it. The only question is how to correctly traverse reverse relationships using ._meta

works & doesn't create intermediary FilterSpec? while traversing model hierarchy

Definitely isn't going to make it into 1.2.

@SmileyChris?: may We do something to make it into 1.2 ? I'm not lobbying :-) With something I meaned some real work

No chance. Since 1.2 beta has been released, we've hit a full feature freeze (and this is definitely a feature).

current patch does not respect limit_choices_to when specified for a ForeignKey.