Mimsy Were the Borogoves

Hacks: Articles about programming in Python, Perl, PHP, and whatever else I happen to feel like hacking at.

42 Astoundingly Useful Scripts and Automations for the Macintosh

Work faster and more reliably. Add actions to the services menu and the menu bar, create drag-and-drop apps to make your Macintosh play music, roll dice, and talk. Create ASCII art from photos. There’s a script for that in 42 Astounding Scripts for the Macintosh.

lookup_allowed gets new parameter for value

Jerry Stratton, February 8, 2011

I’ve updated the lookup_allowed method in SmarterModelAdmin because it looks like (a) there won’t be an official solution in Django 1.3, and lookup_allowed is going to get a new parameter.

[toggle code]

  • class SmarterModelAdmin(admin.ModelAdmin):
    • valid_lookups = ()
    • def lookup_allowed(self, lookup, *args, **kwargs):
      • if lookup.startswith(self.valid_lookups):
        • return True
      • return super(SmarterModelAdmin, self).lookup_allowed(lookup, *args, **kwargs)

Overall this seems like a good change to me. If done right it allows filtering based on value as well as on field.

Hopefully, a later Django will alleviate the need to use an undocumented override. The main reason I didn’t put much work in this solution is that I thought I saw something about there already being a solution in 1.3; sounds like that isn’t the case.

Um. Semi-undocumented.

This was a little annoying:

It’s unfortunate that people are externally documenting the “fix” for the security problem to be “remove the security”, but there’s not much we can do beyond documenting the change.

That is of course untrue. You could provide a sanctioned method for allowing filters on lookups that don’t appear in a list_filter. Saying that adding a valid_lookups property is “removing the security” is saying that their fix isn’t a fix at all, since it removes the security from list_filter fields. In both cases the code is just looking at a list of fields and relations for which admin filtering should be allowed.

Being able to drill into a database is useful, as the existence of list_filter shows. The “hack” that allows building custom admin queries to drill into field values in the admin display is well-known and well-promulgated and if it isn’t in the documentation, it is from the time when the documentation was “read the source”.

In response to Fixing Django 1.2.4’s SuspiciousOperation on filtering: When you get the message “Filtering by keyword not allowed” in Django 1.2.4, here’s one way to fix it.