Go back to old change_list view after hitting save

This has been requested before, see for example #3777. That was closed by submitter after an alternate method was shown that didn't involve changing Django code. I haven't tried it so don't know if it's still directly applicable to newforms-admin but it might give you an idea of an approach.

Ah, I'll look into the patch. Thx! I still think this should be the default behaviour. The question ist: Why wouldn't I want the filters to be persistent? IMHO the user expects this and not the automatic filter reset. Any thoughts?

I agree that preserving the filters is more user-friendly. Personally it doesn't bother me too much in Django admin but that's because I don't happen to use filters in admin that much. However when I run into it in other interfaces it tends to annoy me when some sort of item-edit page's "doit" button returns me to a list that differs from the one I came from to edit the object. So I'd be in favor of the change, but don't have much personal interest in it and think newforms-admin has bigger fish to fry at the moment (specifically anything blocking a merge to trunk).

django-dev discussion is at http://groups.google.com/group/django-developers/browse_thread/thread/4d1f075ff4c92ea0/fd73ec2b916936b0?hl=en&lnk=gst&q=6903#fd73ec2b916936b0

Patch updated to r9781

A few updates to ramiro's patch, and updated to r9888

I've made a few stylistic improvements to the patch, but it still needs some fundamental improvement.

The main problem is that "guessing" the return URL from HTTP_REFERER leads to strange behavior. For example:

• Click "add" from the main admin index, then save the object. Result: you're returned to the index page. No, you should go to the changelist to inspect the object you just added.

• Click "add" from anywhere. Click "save and add another". Click "save". Result: you're taken back to the last object you created. This is really confusing: it appears identical to clicking "save and continue editing", except you've got different values.

This needs to be fixed. I think probably the best approach is to *only* read the return URL from GET, and to modify the changelist to pass the return URL through as a GET variable. That is, rewrite the links from the changelist to include the return URL in the link.

(This means you'll want to choose a different URL keyword to avoid conflicting with a field named return_to. Probably _return_to, I'd say.)

Second, this patch needs some tests. Especially ones to make sure that the redirects stay sane in cases like above.

New patch, including Jacob's changes and suggestions. Thanks Alex Gaynor for his help with the tests

Replying to jacob:

it still needs some fundamental improvement.

The main problem is that "guessing" the return URL from HTTP_REFERER leads to strange behavior.

This needs to be fixed. I think probably the best approach is to *only* read the return URL from GET, and to modify the changelist to pass the return URL through as a GET variable. That is, rewrite the links from the changelist to include the return URL in the link.

I've implemented this change in the new 6903-r9904.diff patch.

(This means you'll want to choose a different URL keyword to avoid conflicting with a field named return_to. Probably _return_to, I'd say.)

done

Second, this patch needs some tests. Especially ones to make sure that the redirects stay sane in cases like above.

done

Jacob, your comment above cleared three of the four doubts I had posted to django-dev after attaching the first revised version of the patch. The only one remaining is this one (I'm reposting because it's a fundamental one and the answer will tell if the approach taken is valid or if we should consider others options discussed like storing things in the session 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?

Milestone post-1.0 deleted

Isn't such a "sticky" behaviour exactly what sessions are for? Why would you not use a session key like request.session['admin_' + <myapp> + '_' + <mymodel> + '_filter'] = {'p':14, 'my_fieldexact':True} and checking for this key when displaying the list of objects of a model?

I'm also offering to try and implement that if this is desired.

Replying to mawimawi:

Isn't such a "sticky" behaviour exactly what sessions are for? Why would you not use a session key like request.session['admin_' + <myapp> + '_' + <mymodel> + '_filter'] = {'p':14, 'my_field__exact':True} and checking for this key when displaying the list of objects of a model? I'm also offering to try and implement that if this is desired.

I'd say got for it and attach it to the ticket so both implementations are available for review and the chances of this feature being available in 1.1 are better.

The idea was that you get an unfiltered list when you go to the changelist URL directly (not coming from an edit form of an entry). mawimawi's example code looks like he wants the filters to stay forever. To cite Malcolm "Yes, from the admin home page it should be a clean view."

I proposed to use the session to store the filters so that you don't pass your filters and search queries around whenever you pass the URL of an edit form to someone else. So I would use a hash of the data and use it as a key in the session. This key would then be passed around instead of the info. But this could be changed later, I don't think it would be backwards incompatible.

Replying to jarrow:

The idea was that you get an unfiltered list when you go to the changelist URL directly (not coming from an edit form of an entry). mawimawi's example code looks like he wants the filters to stay forever. To cite Malcolm "Yes, from the admin home page it should be a clean view." I proposed to use the session to store the filters so that you don't pass your filters and search queries around whenever you pass the URL of an edit form to someone else. So I would use a hash of the data and use it as a key in the session. This key would then be passed around instead of the info. But this could be changed later, I don't think it would be backwards incompatible.

I don't see, why it is a bad thing to be able to post the filter settings around with the url. I consider it a feature, to be able to copy a filtered admin changelist view URL into an email and post it to a colleague to show him exacly what I want him to notice. Using the session would also go against REST (no ambiguous URLs).

Using URLs also automatically solves Malcolms request you mentioned. The admin start page just uses URLs without filter parameters as it always has.

Just my 5 cents.

I proposed to use the session to store the filters so that you don't pass your filters and search queries around whenever you pass the URL of an edit form to someone else. So I would use a hash of the data and use it as a key in the session. This key would then be passed around instead of the info. But this could be changed later, I don't think it would be backwards incompatible.

I don't see, why it is a bad thing to be able to post the filter settings around with the url. I consider it a feature, to be able to copy a filtered admin changelist view URL into an email and post it to a colleague to show him exacly what I want him to notice. Using the session would also go against REST (no ambiguous URLs). Using URLs also automatically solves Malcolms request you mentioned. The admin start page just uses URLs without filter parameters as it always has.

Sure. I totally agree :) What I was talking about was not the changelist view itself. Of course that stays like it is. With an URL that you can copy including the filters. What I meant was: While editing an item - coming from a filtered changelist - it might not be so obvious that if you copy the URL from the edit view and pass it to a fried he will be going back to your custom-filtered change list.

Replying to jarrow:

I proposed to use the session to store the filters so that you don't pass your filters and search queries around whenever you pass the URL of an edit form to someone else. So I would use a hash of the data and use it as a key in the session. This key would then be passed around instead of the info. But this could be changed later, I don't think it would be backwards incompatible.

I don't see, why it is a bad thing to be able to post the filter settings around with the url. I consider it a feature, to be able to copy a filtered admin changelist view URL into an email and post it to a colleague to show him exacly what I want him to notice. Using the session would also go against REST (no ambiguous URLs). Using URLs also automatically solves Malcolms request you mentioned. The admin start page just uses URLs without filter parameters as it always has.

Sure. I totally agree :) What I was talking about was not the changelist view itself. Of course that stays like it is. With an URL that you can copy including the filters. What I meant was: While editing an item - coming from a filtered changelist - it might not be so obvious that if you copy the URL from the edit view and pass it to a fried he will be going back to your custom-filtered change list.

Then I got your proposal wrong. I really don't think anyone wants to copy an URL from an edit page with filters enabled. Forget everything I said. (Note to self: READ, then post)

This has gone around quite a bit, but it's still not quite perfect. It's really a hard problem, unfortunately, and we're out of time to put it in 1.1.

Has anyone thought about this issue of "sticky filters" with respect to the breadcrumbs in the changelist? For example, say I filter my objects in the changelist view and then click on one of the objects to go to its change form. Now my breadcrumbs contain something like:

Home > ObjectManager > Objects > Object_I_Clicked_On

It seems to me that if I click on "Objects" in the breadcrumbs, that I would want to go back to my filtered change list, not the unfiltered change list.

I'm mentioning this because it seems like it would be nice to have a solution that could be extended to solve this as well (assuming others agree that the breadcrumbs should return you to the filtered change list).

Margie

I use a fancy snippet that open related object in change mode (using few lines of jQuery), so I would like to close the window after saving if in popup mode. A call to a dismissChangePopup (similar to dismissAddAnotherPopup) would be great, but for now I add this to response_change function after msg:

        # Close if editing in a popup
        if request.POST.has_key("_popup"):
            return HttpResponse('<script type="text/javascript">window.close();</script>')

Patch fixed for r11616

Without new changes, just for working with 12351 revision in development trunk

1.2 is feature-frozen, moving this feature request off the milestone.