Undocumented admin feature for filtering rows?

[Mingers]

Hi everyone,

I've been working on a problem where I'd like the admin to be able to
filter for rows based on certain conditions for the list display, i.e.
basically anything that can be used as keyword arguments in
<modelname>.objects.filter(**kwargs) should be allowed as a filter for
the list display.

Current solutions aren't good enough:
1) This isn't the same thing as search, which is used mainly for text.
2) List_filter is no good when my range of values is very large (i.e.
if I have 100,000 values I'd be scrolling a long time before I found
the value I wanted), or if I want to get a range of values, say
between 10 and 20.

This would also be nice for things like searching for a blog post
within a date range.

Turns out, this is already partially implemented (by accident?). From
the admin, you can already filter rows for the list display by passing
GET arguments, ie. /admin/<app>/<model>/?
<columnname>__gt=10&<columnname>__lt=20

Well, I'm a django newbie, so you all can correct me if I'm wrong. If
I'm not, it'd be nice if 1) it were documented and 2) if there was an
admin option for models so that you could have this functionality show
up in the admin (some kind of form would need to be designed pretty
much). Thanks.

Best,
Mingers

[Adrian Holovaty]

On Dec 26, 2007 6:10 AM, Mingers <minge...@gmail.com> wrote:
> Turns out, this is already partially implemented (by accident?). From
> the admin, you can already filter rows for the list display by passing
> GET arguments, ie. /admin/<app>/<model>/?
> <columnname>__gt=10&<columnname>__lt=20
>
> Well, I'm a django newbie, so you all can correct me if I'm wrong. If
> I'm not, it'd be nice if 1) it were documented and 2) if there was an
> admin option for models so that you could have this functionality show
> up in the admin (some kind of form would need to be designed pretty
> much). Thanks.

That's an intentional feature for power users who want to be able to
filter changelists more intelligently -- and who happen to know the
Django query syntax. :-)

Making an intensive "advanced search" form would not only be a
significant user interface challenge, it probably falls out of the
scope of what the admin site should do. So given your two options, I'd
suggest we do the first.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[jdetaeye]

Mingers,

I have pretty much the same use case as you: I wanted the filtering in
the admin to be more "like a spreadsheet".

See the screenshot on my website to see how I solved the issue:
http://www.frepple.com/screenshots/miniadmin.png
It allows the user to enter the filter value, select a filter
operator, and also to export the data in CSV-format to a spreadsheet.

The implementation is not based on customizing the admin, but
implementing a generic view with very similar capabilities as the
django changelist view. In all, around 800 lines of code.

My 2 cents,

Johan

[John-Scott Atlakson]

We're using this 'hidden' feature as well, for similar reasons.
I built a search form that allows the user to select multiple parameters to filter by. I just named the form fields using the appropriate lookup form of the field names (for example, a form TextField named user__first_name, etc.). However, fields without values still get added to the GET request (e.g. /?user__first_name='John-Scott'&hometown='') so the problem with this is that the Django ORM then tries to filter results where the User object's first_name is 'John-Scott' AND the hometown is the empty string. I wrote a simple view hack that removes all the parameters with empty values and then redirects to the appropriate admin url so filter() is only passed parameters with values. If this was done in core, this would make this 'power' feature a little more easy to use. I think it could be as trivial as a change to get_query_string() in django.contrib.admin.views.main.Changelist that deletes keys with empty values. I could take a stab at writing up a patch if anyone else is interested.

Cheers,
John-Scott

[Mingers]

Well always good to hear confirmation that my use case isn't crazy.

Johan, that looks great. It's what I would want to be able to do in
the admin. I'd say I'm a big fan of spreadsheet like views as well.
I've used FoxPro, and though it ain't a pretty language, it's database
viewer is great--write SQL queries and browse the result table right
away. Really great for massaging data into a form you want.

John-Scott, I agree that it would be nice to be implemented in the
core and would be interested, but what do you think of the case where
the user is interested in all rows where a certain field is blank
(maybe something like "all rows where age is blank")?

Mingers
On Dec 27, 6:42 am, John-Scott Atlakson

[Nathaniel Whiteinge]

On Dec 26 2007, 2:50 pm, jdetaeye <johan.de.ta...@gmail.com> wrote:
> The implementation is not based on customizing the admin, but
> implementing a generic view with very similar capabilities as the
> django changelist view. In all, around 800 lines of code.

Johan, that screenie looks very nice. Any chance you're able to share
that code?

[jdetaeye]

The code is part of my open source project frePPLe.
It'll take you a while to untangle the part you're interested in from
the rest...

The code also handles some additional functionalities:
- support for "table" reports, where time buckets are represented as
columns
- allow raw sql to generate the report data
- use of 'last-modified' html-header to avoid unnecessary recomputing
of the (complex) database query
- uses admin-like syntax to define the reports

The report code in held in this file:
http://frepple.svn.sourceforge.net/viewvc/*checkout*/frepple/trunk/contrib/django/freppledb/utils/report.py?revision=629&content-type=text%2Fplain

The javascript code:
http://frepple.svn.sourceforge.net/viewvc/frepple/trunk/contrib/django/freppledb/static/frepple.js?view=markup
My code uses the prototype javascript library and also handles other
context menu in the application, so you might be better off starting
from scratch according to your needs and taste.
The main trick in choosing the filter operator is to dynamically
change the "name" property of some form fields. For instance the
orginal html-form may have:
<input name="myfield_gte" value="10"/>
which is changed with some javascript to:
<input name="myfield_lt" value="10"/>

In the future I am planning to further enhance the functionality.
On the wishlist:
- ability to import csv formatted data
- ability to sort on multiple columns

If there is sufficient interest this could be turned in a reusable
component. People could then use it as a replacement for the standard
object-list admin screens.

Regards,

Johan

[Tai Lee]

+1 interested party ;)