Issue Details (XML | Word | Printable)

Key: SAK-8115
Type: Feature Request Feature Request
Status: Closed Closed
Resolution: Duplicate
Priority: Major Major
Assignee: Unassigned
Reporter: Peter A. Knoop
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Sakai

Sakai Saving State - Moving between tools and within pages of a tool should behave conistently for users.

Created: 30-Jan-2006 12:15   Updated: 30-Jan-2007 09:09
Component/s: Portal
Affects Version/s: 2.2.0

Issue Links:
Duplicate
Relate
 


 Description  « Hide
User need a consistent model for what will happen when they "go someplace else" within Sakai.

Currently, when you move between tools sometimes the tool the user left remains in the same state so when the user returns, they are dropped in the middle of a tool. For other tools, the tool resets itself when a user leaves it so when the return to the tool they arrive at the main page.

There is similar inconsistency with navigating within a tool. Sometimes, moving away from a page (but staying within the tool) saves the users data on page (a form for instance) until they come back. And in other tools, if the user moves away from a page without saving, the data will not be saved and the next time they visit that page it will be refreshed.

Original requirement below before combining this one with another:

Currently Sakai saves the state of a tool when you navigate away from it. For instance, if you are part way through creating a Resource and you click on the Schedule, when you come back to Resources, you'll find yourself right where you left off creating a new Resource, which can lead to confusion if you do not want to resume the process, are looking to do something different in Resources now, and are not familiar with the reset button for tools. Another approach is to reset a tool, and not save its state, when you navigate away from it, which means when you come back, if you want to resume your process, then you've lost everything you've done up to that part and have to start over. (Some other aspects of Sakai's behavior, which may compound the problems experienced here, include lack of support for the browser's back button and the percieved expectation that clicking on a tool in the left-hand menu, when already viewing the tool, should reset the tool, as opposed to learning about the little reset-icon in the top-left of the tool.)


There has always been a lot of debate over which model to adopt. The choice of saving state or not should be a system-wide configuration option.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Daphne Ogle added a comment - 17-Feb-2006 14:36
Updated description for clarity and combined language from a requirement I had added that really included this issue with another one. I removed the saving state language from the other.

UI group done with this one.

Charles Severance added a comment - 15-Sep-2006 03:27
This is a provisional feature for Sakai 2.3

14687 and 14596

portal.experimental.auto.reset=true

Peter A. Knoop added a comment - 15-Sep-2006 05:51
See SAK-737 for implementation details and progress going forward.