Proposal: Make filters in admin persistent (#6903)

44 views
Skip to first unread message

Jonas Pfeil

unread,
Nov 11, 2008, 8:19:00 AM11/11/08
to Django developers
Currently if you search in the admin, use some kind of filter or even
just go to the second page in the change list this selection is reset
when you edit an item and hit save. The user gets the default list
again. Needless to say this can be quite annoying. Especially if you
want to edit a specific subset of a very large database.

The solution is to somehow make the filters persistent. The ticket [1]
already has a patch.

Cheers,

Jonas

[1] http://code.djangoproject.com/ticket/6903

David Cramer

unread,
Nov 11, 2008, 4:35:52 PM11/11/08
to Django developers
Before this gets accepted, I'd like to throw in the proposal of
storing this in the session vs a huge URL. That and a hash seem to be
the common approach to storing search paths.

George Vilches

unread,
Nov 11, 2008, 4:39:12 PM11/11/08
to django-d...@googlegroups.com
I definitely second this. The extra bonus to storing it in the
session is that you can maintain your search state on multiple admin
pages/models independently without overflowing the URL. Naturally if
you do it this way, you'd also want to have a visible "clear filters"
link so that there's some way to reset that state, I didn't check the
patch to see if this was already included.

David Cramer

unread,
Nov 11, 2008, 4:47:26 PM11/11/08
to Django developers
Well I'm not sure storing multiple search paths is too good of an
idea, as you increase the size of the session significantly, and then
have to worry about expiring those or clearing them somehow. The
session just keeps it for that users session, vs whoever else happens
to visit that url (say I pass it off to a coworker).

George Vilches

unread,
Nov 11, 2008, 4:51:38 PM11/11/08
to django-d...@googlegroups.com
Don't sessions already have standard expirations in them? Besides
that, this is the admin, it's not a tool for every user of your
application to be in, so there will only be a few larger sessions (and
larger is still only a few K at most, if you have lots and lots of
models you're filtering on). And yes, it would only keep it for the
length of that user's session, I don't magically expect it to be able
to suddenly transfer to another user. If I wanted that functionality,
I would ask for something to be added to the admin that would print
out a URL that you could give to another user to get the filtering you
were just using. Which sounds handy, but is a separate ticket from
what we're discussing here.

David Cramer

unread,
Nov 11, 2008, 5:34:28 PM11/11/08
to Django developers
I guess you're right. This is just for admin so it's not a huge deal.

It will feel weird howerver, if I somehow go to a search results page
and it remembers my filters when I was visiting something else before
that. So it'd need to handle clearing it at the right time as well.

George Vilches

unread,
Nov 11, 2008, 5:39:05 PM11/11/08
to django-d...@googlegroups.com
I wasn't thinking that the filters would be preserved across
*different* models or admin pages, only within them. So, you'd keep
some sort of dictionary, keyed based on the particular admin URL,
model, or some other easily achievable unique piece of information per
screen. I wouldn't expect that just because I was filtering on e-mail
address in one section of the admin app, it would automagically apply
that filter wherever else it could. :)

Would preserving filters open the door to also preserving the current
ordering and current page number in the admin view? I would suspect
that if you're saving one, you'd really want to save all three,
because they all go together insofar as returning you to *exactly* the
view you were last using. If you're going to preserve it at all,
might as well do it right and preserve it as pristinely as possible.

David Cramer

unread,
Nov 11, 2008, 6:50:51 PM11/11/08
to Django developers
I was implying that if I'm in email admin, and there's filters there,
once I leave email admin, there's no reason to keep that information
around. Going back to the email admin should give a clean start,
that's how typical applications like that work (at least every one
that I've ever used).

But yes, you'd want to preserve any GET params most likely. Easiest to
just save the URL.

Malcolm Tredinnick

unread,
Nov 13, 2008, 8:15:53 PM11/13/08
to django-d...@googlegroups.com

On Tue, 2008-11-11 at 13:47 -0800, David Cramer wrote:
> Well I'm not sure storing multiple search paths is too good of an
> idea, as you increase the size of the session significantly, and then
> have to worry about expiring those or clearing them somehow. The
> session just keeps it for that users session, vs whoever else happens
> to visit that url (say I pass it off to a coworker).

This last point is exactly why putting it in the URL is the better
solution. It's the whole idea behind addressable resources. You can then
pass around the right filtered view to a colleague via email for further
work. Or you can record it in an issue tracker. Or bookmark it to come
back to later on.

Storing it in the session would throw away all those benefits. We're
developing for the web here; let's use the advantages of the medium,
rather than doing all the work and then only making it available to the
single person viewing it at that moment.

Persistent filters makes sense; we should do that. But in the URL if at
all possible, since it's best practice.

Regards,
Malcolm


Jonas Pfeil

unread,
Nov 14, 2008, 11:28:32 AM11/14/08
to Django developers
Just to be clear we are talking about the same thing: With "persistent
filters" I just mean "going back to the _filtered_ change list after
editing an item". I don't think it makes sense to make them any more
persistent :) Clicking on the link to the change list on the admin
home page should give a fresh start.

On Nov 14, 2:15 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Persistent filters makes sense; we should do that. But in the URL if at
> all possible, since it's best practice.

The change list should really have an URL that includes the filters.
It's a different resource after all. I don't know if the "passing URLs
to a friend" argument is really fitting on the URL of the edit view of
an item though. If we use a from_url GET parameter that would take my
colleague back to _my_ filtered change list. I don't know if this
makes sense, but doesn't really hurt I suppose. Except that it may,
unintentionally, leak the information you searched for to another
person. If we don't want this we could put the information in the
session and use a hash.

So maybe it's best to use GET parameters as before for the change
list, but store the from_url in the session under a hash that we set
as a GET parameter for the editing process. Just using the session
wouldn't cut it, as we need to track multiple edit actions in
parallel.

Cheers,

Jonas

Malcolm Tredinnick

unread,
Nov 14, 2008, 9:05:47 PM11/14/08
to django-d...@googlegroups.com

On Fri, 2008-11-14 at 08:28 -0800, Jonas Pfeil wrote:
> Just to be clear we are talking about the same thing: With "persistent
> filters" I just mean "going back to the _filtered_ change list after
> editing an item". I don't think it makes sense to make them any more
> persistent :) Clicking on the link to the change list on the admin
> home page should give a fresh start.

Yes, from the admin home page it should be a clean view. But that's not
the only way to access the change list. You can got there directly since
the web (and Django) uses addressable resources and the change list page
is a resource in that respect. Filtered views of the change list are
also resources and should have their own addresses, since they're
different from the unfiltered view. In that fashion, returning to the
filtered view from the add/change page and from a bookmark, email or
other means are all possible. Simple solutions tend to stand out like
that: they solve multiple problems at once.

There's simply no reason to say that the *only* way to get directly to a
filtered few is from add/change. That's a restriction without cause.

Regards,
Malcolm


Ramiro Morales

unread,
Jan 23, 2009, 5:36:55 AM1/23/09
to django-d...@googlegroups.com

I've updated the existing patch created by slonopotamus for this ticket
and intend to working on it hopefully making it worth considering for
inclussion.

I haven't, so far, changed anything fundamental, and wanted to ask for
advice and opinions about the patch and in regard to what has been already
discussed in this thread.

First, I've found that the concern about the filtered changelist views
in the admin app being addresssable resources only by using the query
string are already covered by the current implementation so that part
isn't something that needs to be solved ((am I wrong about this?)

I've listed below a few notes about the patch, some of them with my
questions attached:

Currently, it:

* Gets the URL where the the user should be taken back after the
CRUD operation from the Referer HTTP request header, Is this a valid
approach? Or should Jonas above ideas about storing it in the session
be implemented instead?

* It passes that URL around from view to view by using an query string
value until the time to use it comes, it does so even when a POST
request is sent (when editing or creating a model instance).
Are we ok with this?

* (Related to the previous item) The variable name used was
'admin_change_return_to', I've changed it to 'return_to'. Do we need
to obfuscate somehow it to make it less prone to clash with other vars?

* It uses the quote function from of urllib. Should
django.contrib.admin.util.quote
or django.util.http.urlquote be used instead?

Thanks for any feedback.

--
Ramiro Morales

Reply all
Reply to author
Forward
0 new messages