#8166 closed enhancement (fixed)
Provide feedback when preferences are saved
Reported by: | Remy Blank | Owned by: | Remy Blank |
---|---|---|---|
Priority: | low | Milestone: | 0.11.5 |
Component: | general | Version: | 0.11-stable |
Severity: | minor | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
In the preferences pannels, when the user clicks on "Save changes", the displayed page doesn't change. This may be confusing, as the user has no feedback whether or not her settings have been saved.
I suggest we add a notice at the top of the page that says "Your preferences have been saved" after saving changes.
Attachments (1)
Change History (8)
comment:1 by , 16 years ago
follow-up: 3 comment:2 by , 16 years ago
I'd like to use the same mechanism as required to solve this for #5350, to show a message when trac.ini
could not be saved.
It seems that the standard way of implementing such messages is to put the messages into the session store prior to the redirect, then to retrieve it in the GET and display it. At least that's what Drupal does.
It seems to me that this has a race condition. What if I submit a form using POST in one tab, and at the same time I GET the result page in another tab? Both tabs will share the same session, and I risk seeing the messages due to the POST in the other tab.
Is there a better way?
comment:3 by , 16 years ago
Replying to rblank:
It seems to me that this has a race condition. What if I submit a form using POST in one tab, and at the same time I GET the result page in another tab? Both tabs will share the same session, and I risk seeing the messages due to the POST in the other tab.
We could use the referer path info for a part of the session key, e.g. 'redirect.notice./prefs/datetime'. There still would be a race condition if both updates tabs are modifying the same setting, but well…
comment:4 by , 16 years ago
Ooh, good idea. What is in the referer path info after a redirect? The URL of the POST, or the URL of the page containing the form that was submitted?
How about adding a randomly-generated _msg
parameter to the redirect URL, so for example, the redirect after submitting a ticket comment would look like:
http://site/ticket/3?_msg=123456
Makes the URL look ugly, though.
by , 16 years ago
Attachment: | 8166-post-redirect-messages-r8179.patch added |
---|
Patch against 0.11-stable adding post-redirect messages
comment:5 by , 16 years ago
The patch above implements a simple version of generic post-redirect messages:
- Any messages added with
add_warning()
andadd_notice()
are saved in the session data in case of a redirect, and are re-added when the nextxhtml
page is displayed.
- I have added the notices to many locations, in fact every time one cannot be sure if an action has been performed or not.
- There is currently no mechanism to avoid the race condition mentioned in comment:2. While slightly unclean and leading to confusion in rare cases, it's how many web applications handle this, and it seem to be good enough, at least in my limited testing.
I like the result (except maybe for the green color, which is a bit aggressive IMO. Maybe we could change it to something lighter). Comments and testing welcome.
comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I don't know how you plan to implement this, but it would be nice to have a generic mechanism to add "info" notices after POST/redirect/GET sequences.