Django

Code

Ticket #6903 (new)

Opened 2 years ago

Last modified 6 days ago

Go back to old change_list view after hitting save

Reported by: jarrow Assigned to:
Milestone: Component: django.contrib.admin
Version: SVN Keywords:
Cc: sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol, marcoberi@gmail.com, joh Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description (Last modified by ramiro)

When editing something via the admin I could observe a recurring usage pattern on myself:

  1. Search for something (e.g. by time, filter, phrase) wanting to edit them all or just go through the pages till I found a certain timespan
  2. Edit
  3. Hit save
  4. Hit the back button two times to get my former list
  5. Repeat with 2. :)

While this may be ok for myself my client is protesting ;) So I thought I'll hack it. But then again, isn't the desired behaviour to go back to the exact collection of stuff in the change list that was there before anyway?

So I'd like to propose to change that. I'm happy to try and write a patch for it, if this get's accepted.

Cheers!

Jonas

Attachments

return_to_old_change_list.diff (4.8 kB) - added by slonopotamus on 07/12/08 09:13:58.
6903-r9781.diff (4.5 kB) - added by ramiro on 01/22/09 07:50:51.
Patch updated to r9781
6903-changelist-return-to.diff (8.2 kB) - added by jacob on 02/23/09 10:13:38.
A few updates to ramiro's patch, and updated to r9888
6903-r9904.diff (14.7 kB) - added by ramiro on 02/25/09 08:21:03.
New patch, including Jacob's changes and suggestions. Thanks Alex Gaynor for his help with the tests
6903-r11616.diff (14.6 kB) - added by marcob on 10/10/09 15:28:20.
Patch fixed for r11616
6903.r12351.current.diff (13.3 kB) - added by ramusus on 01/29/10 12:07:54.
Without new changes, just for working with 12351 revision in development trunk

Change History

03/27/08 09:19:06 changed by Karen Tracey <kmtracey@gmail.com>

  • keywords set to nfa-someday.
  • needs_better_patch changed.
  • stage changed from Unreviewed to Design decision needed.
  • needs_tests changed.
  • needs_docs changed.

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.

03/27/08 09:35:34 changed by jarrow

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?

03/27/08 11:33:02 changed by Karen Tracey <kmtracey@gmail.com>

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).

06/16/08 16:12:38 changed by ramiro

  • description changed.

07/12/08 09:13:27 changed by slonopotamus

  • owner changed from nobody to slonopotamus.
  • has_patch set to 1.

07/12/08 09:13:58 changed by slonopotamus

  • attachment return_to_old_change_list.diff added.

07/12/08 09:14:23 changed by slonopotamus

  • owner changed from slonopotamus to nobody.

07/14/08 02:08:10 changed by slonopotamus

  • keywords changed from nfa-someday to nfa-someday yandex-sprint.

08/18/08 10:40:09 changed by ericholscher

  • milestone set to post-1.0.

12/15/08 12:34:01 changed by niels

  • cc set to niels.busch@gmail.com.

01/20/09 17:34:37 changed by ramiro

  • owner changed from nobody to ramiro.
  • needs_better_patch set to 1.
  • needs_tests set to 1.

01/22/09 07:50:51 changed by ramiro

  • attachment 6903-r9781.diff added.

Patch updated to r9781

02/17/09 04:53:31 changed by niels

  • cc deleted.

02/23/09 10:13:38 changed by jacob

  • attachment 6903-changelist-return-to.diff added.

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

(follow-up: ↓ 13 ) 02/23/09 10:20:45 changed by jacob

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.

02/25/09 08:21:03 changed by ramiro

  • attachment 6903-r9904.diff added.

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

(in reply to: ↑ 12 ) 02/25/09 08:47:41 changed by ramiro

  • needs_better_patch deleted.
  • needs_tests deleted.

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?

02/25/09 13:51:44 changed by

  • milestone deleted.

Milestone post-1.0 deleted

02/26/09 14:02:47 changed by sixthgear

  • cc set to sixthgear.

03/04/09 02:41:02 changed by ramiro

  • keywords deleted.
  • version changed from newforms-admin to SVN.
  • milestone set to 1.1.

(follow-up: ↓ 19 ) 03/06/09 14:09:52 changed by 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_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.

03/09/09 21:40:12 changed by gonz

  • cc changed from sixthgear to sixthgear, gonz.

(in reply to: ↑ 17 ) 03/17/09 15:15:41 changed by ramiro

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.

03/18/09 04:49:31 changed by ramiro

  • milestone changed from 1.1 to 1.1 beta.

(follow-up: ↓ 22 ) 03/18/09 08:59:06 changed by 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.

(in reply to: ↑ 21 ; follow-up: ↓ 23 ) 03/19/09 13:49:53 changed by mremolt

  • cc changed from sixthgear, gonz to sixthgear, gonz, mremolt.

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.

(in reply to: ↑ 22 ; follow-up: ↓ 24 ) 03/19/09 14:42:25 changed by 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.

(in reply to: ↑ 23 ) 03/19/09 14:47:27 changed by mremolt

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)

03/23/09 15:49:35 changed by jacob

  • milestone changed from 1.1 beta to 1.2.

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.

06/03/09 12:03:18 changed by margieroginski

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

07/20/09 05:09:19 changed by ramusus

  • cc changed from sixthgear, gonz, mremolt to sixthgear, gonz, mremolt, ramusus@gmail.com.

08/07/09 18:53:35 changed by spinyol

  • cc changed from sixthgear, gonz, mremolt, ramusus@gmail.com to sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol.

08/21/09 20:34:57 changed by marcob

  • cc changed from sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol to sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol, marcoberi@gmail.com.

08/21/09 21:19:04 changed by marcob

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>')

10/10/09 15:28:20 changed by marcob

  • attachment 6903-r11616.diff added.

Patch fixed for r11616

01/10/10 09:24:20 changed by ramiro

  • owner deleted.

01/29/10 12:07:54 changed by ramusus

  • attachment 6903.r12351.current.diff added.

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

02/23/10 18:00:00 changed by ubernostrum

  • milestone deleted.

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

03/10/10 20:03:39 changed by joh

  • cc changed from sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol, marcoberi@gmail.com to sixthgear, gonz, mremolt, ramusus@gmail.com, spinyol, marcoberi@gmail.com, joh.

Add/Change #6903 (Go back to old change_list view after hitting save)




Change Properties
Action