Ticket #8166 (closed enhancement: fixed)
Provide feedback when preferences are saved
| Reported by: | rblank | Owned by: | rblank |
|---|---|---|---|
| Priority: | low | Milestone: | 0.11.5 |
| Component: | general | Version: | 0.11-stable |
| Severity: | minor | Keywords: | |
| Cc: |
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
Change History
comment:2 follow-up: ↓ 3 Changed 16 months ago by rblank
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 in reply to: ↑ 2 Changed 16 months ago by cboos
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 Changed 16 months ago by rblank
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.
Changed 15 months ago by rblank
-
attachment
8166-post-redirect-messages-r8179.patch
added
Patch against 0.11-stable adding post-redirect messages
comment:5 Changed 15 months ago by rblank
The patch above implements a simple version of generic post-redirect messages:
- Any messages added with add_warning() and add_notice() are saved in the session data in case of a redirect, and are re-added when the next xhtml 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.



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.