#80
- Created on2010-01-12 15:26
- Reported by
- StatusNew
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
conflict resolution for 'concurrent' edits
The way gallery is handling it now is all or nothing, if someone edits and saves while you are in the midst of an edit, you are forced to retrieve his or her changes and make a decision about your edit.
Right now, for that scenario, we display, "Your change cannot be completed because somebody else has made a conflicting change to the same item. Use the back button in your browser to go back to the page you were on, then <b>reload that page</b> and try your change again."
What we might do, would be to save, along with the serial number, the list of affected fields, and then, for each edit, if the serial number is out of date, check to see if there would be a conflict, and if not, proceed to complete the edit, otherwise, do something similar to what it does now (i.e. force a review). This would mean, for example, that one person could edit the description while another edits the title. Also, with this approach, since we would know the specifics, we could do something nice with ajax where potentially conflicting fields are brought down as the user is editing.
Obviously we want to weigh the value-add here with time we'd need to spend in QA and going over the internals to make sure it is done right. It is also an open question as to how much time and effort we'd want to put into the Gallery 2 architecture given that it is legacy code at this point.
Right now, for that scenario, we display, "Your change cannot be completed because somebody else has made a conflicting change to the same item. Use the back button in your browser to go back to the page you were on, then <b>reload that page</b> and try your change again."
What we might do, would be to save, along with the serial number, the list of affected fields, and then, for each edit, if the serial number is out of date, check to see if there would be a conflict, and if not, proceed to complete the edit, otherwise, do something similar to what it does now (i.e. force a review). This would mean, for example, that one person could edit the description while another edits the title. Also, with this approach, since we would know the specifics, we could do something nice with ajax where potentially conflicting fields are brought down as the user is editing.
Obviously we want to weigh the value-add here with time we'd need to spend in QA and going over the internals to make sure it is done right. It is also an open question as to how much time and effort we'd want to put into the Gallery 2 architecture given that it is legacy code at this point.
Leave a comment
on 2010-01-12 18:58 *
By rrsIPOV
Assigned to set to joseph.gay
Milestone changed from Backlog to Sprint 23
Other than implementing versioning, we could some something a little easier - try (it won't always work) and detect that someone else already has a "edit" page open and either show an error immediatly (not as nice) or show the page in a read-only mode (at least for text box heavy pages) so that someone can see and copy the data, just not try and edit.
on 2010-02-25 12:13 *
By joseph.gay
The proactive locking approach may be the simplest thing to do that will result in a better user experience. There are still important decision points. The basic idea is that when a user accesses an edit page, we know that he or she may make a change in the near term. This means that, for the original user's session, as long as he or she doesn't navigate away, given a reasonable timeout, we can assume that any other user accessing the same edit page might end up losing work or causing the original user to lose work as a result of an edit.
Here are some questions. How long should the timeout be before we decide a user has just abandoned the edit page? Should we prevent users other than the original accessor from performing edits, or just warn them that a another user has recently accessed the same page?
On a technical level, do we implement this as a new database table that will map session ids to a unique item edit identifier, or do we add something to the existing session table to indicate the last edit page access for that session?
Here are some questions. How long should the timeout be before we decide a user has just abandoned the edit page? Should we prevent users other than the original accessor from performing edits, or just warn them that a another user has recently accessed the same page?
On a technical level, do we implement this as a new database table that will map session ids to a unique item edit identifier, or do we add something to the existing session table to indicate the last edit page access for that session?