Feature #2621

Errors when editing an issue that was just edited - StaleObjectError

Added by Eric Davis over 10 years ago. Updated over 7 years ago.

Status:ClosedStart date:2009-01-29
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:Duplicate

Description

What should happen

  1. User A opens issue #100 and starts to update it with content and files
  2. User B opens issues #100, changes the status, and saves
  3. User A submits the form
  4. Images are uploaded
  5. Redmine finds User A's data was stale
  6. Redmine redirect User A to the edit form with the data User A has seen but without a stale lock
  7. Redmine displays User A's comment and time entry data properly in the form
  8. Redmine displays an Error message saying the data was updated by another user
  9. User A checks the form and resubmits
  10. Redmine saves User A's data

Bugs

8. The error should say which data was updated. Since User B changed the Status it should say "Status was changed to XYZ"

9. Re-submitting the form fails because Redmine is using the stale lock and not a fresh one. Since the lock is never renewed, the user will be unable to submit the form successfully.

I have working code and will integrate it once it's been tested and cleaned up

stale-error-messages.png (56.8 KB) Eric Davis, 2009-12-09 01:16

0001-Handle-the-StaleObjectError-when-two-users-edit-the-.patch Magnifier (12 KB) Eric Davis, 2009-12-09 01:18


Related issues

Related to Redmine - Defect #3846: issue edit accepts attachment even if the change is rejec... Closed 2009-09-10

History

#1 Updated by Jean-Philippe Lang over 10 years ago

Re-submitting the form fails because Redmine is using the stale lock and not a fresh one.

It prevents user B from overwriting user A's changes by simply re-submitting the form.
Surely, it's a poor design but it's not a defect.

#2 Updated by Jean-Philippe Lang over 10 years ago

  • Tracker changed from Defect to Feature

#3 Updated by Eric Davis over 10 years ago

Jean-Philippe Lang wrote:

It prevents user B from overwriting user A's changes by simply re-submitting the form.
Surely, it's a poor design but it's not a defect.

It puts the user into a position where they either lose their data or have to copy and paste it all into a new browser tab, hence the defect. If you look the form when there is a conflict, there is a hidden field for lock_version that is the stale lock. So at that point, the user cannot ever submit the form, even if they reconcile the differences. If the error is going to be handled by displaying a form, then the form should be functional.

#4 Updated by Eric Davis almost 10 years ago

I've attached a patch to fix thi, I've ran into it many times and every time I lose data. This patch fixes several things and makes the user interface more friendly (I hope):

  • When a conflict occurs, the user can submit their change
  • The conflicting fields are shown to the user (in Red)
  • File attachments that failed are saved and re-associated (this reverts the fix in r2875 / #3846. If the user just spent a bunch of time to upload a large file, deleting it could make them unhappy).

I'm ready to commit this fix if it looks good.

Here's a screenshot of what the user would see if a conflict occurred.

#6 Updated by Robert Chady almost 10 years ago

It does not appear to list any journal entries that accompany the updates. Could you include the journal entries that go with the changes so the user has all the information available to them?

#7 Updated by Jean-Philippe Lang almost 10 years ago

  • Target version changed from 0.9.0 to 1.0.0 (RC)

I prefer that we take some time before this gets added to a stable branch.
And it's a bit late for 0.9.

#8 Updated by Alexey Palazhchenko over 9 years ago

Part of BugMash 1.0…

#9 Updated by Eric Davis over 9 years ago

  • Priority changed from High to Normal
  • Target version changed from 1.0.0 (RC) to 1.1.0

Pushing to a later release. If I can get me some more feedback on the UI I can update the patch.

#10 Updated by Eric Davis almost 9 years ago

  • Assignee deleted (Eric Davis)

#11 Updated by Jean-Philippe Lang almost 9 years ago

  • Target version changed from 1.1.0 to Unplanned backlogs

1.1 feature freeze.

#12 Updated by Etienne Massip over 8 years ago

  • Target version changed from Unplanned backlogs to Candidate for next major release

#13 Updated by Jean-Philippe Lang over 7 years ago

  • Status changed from 7 to Closed
  • Target version deleted (Candidate for next major release)
  • Resolution set to Duplicate

Superseded by #8691 which is fixed for 1.4.0.

Also available in: Atom PDF