View Issue Details

IDProjectCategoryView StatusLast Update
0005466mantisbtbugtrackerpublic2014-12-08 00:34
Reporterhinke Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.0a1 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0005466: Changes are overwritten
Description

If an issue is opened by two users and first updated by one of them and then by the other, the first changes are overwritten.

Additional Information

Our proposal is to use optimistic record locking to solve this.

TagsNo tags attached.

Relationships

related to 0009856 closedjreese Implement method for tracking changes to Description, Steps to Reproduce, and Additional Info 
has duplicate 0009899 closedvboctor Prevent loss of data during simultaneous updates 
has duplicate 0008088 closeddregad Data is overwritten by another data when two persons are editing a same issue. 
has duplicate 0019699 closedatrol MIssing Data Lock on Issue Edit 
has duplicate 0008961 closedatrol Multiple writing accesses allowed for the same record 
related to 0017589 closedgrangeway "Assign To" does not work on page view.php 

Activities

giallu

giallu

2008-11-26 17:53

reporter   ~0020072

this is called "mid air collision" in BugZilla

giallu

giallu

2008-11-26 18:28

reporter   ~0020073

John, I can't see how these are related...

olegos

olegos

2008-11-26 19:14

reporter   ~0020074

@giallu, is it a collision in BugZilla only when the same field is modified, or when any changes are made concurrently, even to different fields? In Mantis it's the latter, which makes the fact that it's not handled or even detected much worse (so a user just updating Description can silently undo someone else's changes to Summary).

jreese

jreese

2008-12-02 09:45

reporter   ~0020182

I considered it related because this is one of the root causes for my work on 9856, because collisions like this in any of the longtext fields have no manner of content tracking, unlike other fields where you can simply look at what it used to be...

Granted, we still need a "real" fix for this. I'm just not sure what that would be at the moment without a huge increase in complexity of schema and API...

olegos

olegos

2008-12-02 16:22

reporter   ~0020200

How about:

  1. When the Update form is presented, compute checksums for all text fields, put them into hidden fields in the form
  2. When the form is submitted
    a. Compare checksums of current entries to the saved ones to figure out what changed
    b. Get the bug from the database again, and compare checksums of the fields changed by the user to the saved ones, to see if the same fields changed in the DB.
    c. Display appropriate message and refuse update, or proceed with the update.

No schema changes, and sounds less complicated to me than what you're doing (although of course what you're doing has other good benefits).

giallu

giallu

2008-12-02 16:53

reporter   ~0020202

So are you telling me that instead of fixing the underlying problem we add more stuff that can break? ;)

IIRC, the system Bugzilla is implementing basically add to the update form an hidden field with the current last_modified value. If another user modify the bug in the meanwhile, when you post the form your last_modified does not match and the change is refused (this should answer olegos question).

This is a simple (and surely improvable) approach, but AFAICT it shouldn't touch the schema and requires minimal modifications to the code.

Do you think it could work for us?

vboctor

vboctor

2009-10-10 01:50

manager   ~0023120

We should use the "last modified" approach. I have a feel that I wrote this before in an issue that is probably a duplicate of this.

blackfox

blackfox

2011-09-15 10:16

reporter   ~0029727

Any chance to get this little change into one of the next versions?
In my opinion the "las modified" approach would be enough - the most important thing is, that lost updates are prevented and the user is notifyed about the conflict...

MLCrane

MLCrane

2014-06-13 04:14

reporter   ~0040802

Last edited: 2014-06-13 04:18

Three years on and I can't believe I'm about to +1 this because it's still happening. I'm prepared to sponsor/have a go at fixing it myself though...

To add to the mix, there are any number of possible ways to detect (a new table for active edits; problems if a session crashes, only saving changed fields; lot of work to detect the changes, etc) but the hidden "Last Modified" is the simplest to implement. I have a feeling my employer wants the "only save changed fields, so different edits of the same issue don't conflict" approach, but I'm blowed if I'm going down that road for code I may not be able to release...

dregad

dregad

2014-06-13 12:38

developer   ~0040804

I'm prepared to sponsor/have a go at fixing it myself though...

Fixing it yourself is definitely the best way to see it implemented in the short term. If you do end up writing code, please submit it for review and eventual merge with core via a Github pull request.

MLCrane

MLCrane

2014-06-17 12:08

reporter   ~0040826

Last edited: 2014-06-18 17:33

I've fixed it in master and sent on a pull request (my github username is PantsManUK). BTW, I much prefer the new 1.3.0dev code, it's so much cleaner to work with than the 1.2.x code, well done to you all!

https://github.com/mantisbt/mantisbt/pull/212

dregad

dregad

2014-07-07 08:33

developer   ~0040894

I marked 0008088 as duplicate. For the record, the discussion there included another patch proposal.

Related Changesets

MantisBT: master 4ef0e69b

2014-06-17 07:56

PantsManUK

Committer: dregad


Details Diff
Detect and block conflicting edits

Fixes the (oh so old) issue on the MantisBT site 0005466, whereby
concurrent edits to a single issue can overwrite field data.

These changes allow MantisBT to spot a conflicting edit, stopping
it from overwriting the first edit with the second. It's very much
a blunt tool (flat-out refusal to save), but it works.

Signed-off-by: Damien Regad <dregad@mantisbt.org>

- Error message revised as discussed in the pull request
- Squashed commits

Fixes 0005466, PR https://github.com/mantisbt/mantisbt/pull/212
Affected Issues
0005466
mod - bug_change_status_page.php Diff File
mod - bug_update.php Diff File
mod - bug_update_page.php Diff File
mod - core/constant_inc.php Diff File
mod - lang/strings_english.txt Diff File