View Issue Details

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

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.


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 




2008-11-26 17:53

reporter   ~0020072

this is called "mid air collision" in BugZilla



2008-11-26 18:28

reporter   ~0020073

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



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).



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...



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).



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?



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.



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...



2014-06-13 04:14

reporter   ~0040802

Last edited: 2014-06-13 04:18

View 2 revisions

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...



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.



2014-06-17 12:08

reporter   ~0040826

Last edited: 2014-06-18 17:33

View 4 revisions

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!



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 11:56:24


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 <>

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

Fixes 0005466, PR
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

Issue History

Date Modified Username Field Change
2005-04-20 10:08 hinke New Issue
2008-11-26 01:05 vboctor Relationship added has duplicate 0009899
2008-11-26 01:06 vboctor Status new => acknowledged
2008-11-26 17:53 giallu Note Added: 0020072
2008-11-26 18:23 jreese Relationship added related to 0009856
2008-11-26 18:28 giallu Note Added: 0020073
2008-11-26 19:14 olegos Note Added: 0020074
2008-12-02 09:45 jreese Note Added: 0020182
2008-12-02 16:22 olegos Note Added: 0020200
2008-12-02 16:53 giallu Note Added: 0020202
2009-10-10 01:50 vboctor Note Added: 0023120
2011-09-15 10:16 blackfox Note Added: 0029727
2014-06-13 04:14 MLCrane Note Added: 0040802
2014-06-13 04:18 MLCrane Note Edited: 0040802 View Revisions
2014-06-13 12:38 dregad Note Added: 0040804
2014-06-17 12:08 MLCrane Note Added: 0040826
2014-06-17 12:10 MLCrane Note Edited: 0040826 View Revisions
2014-06-17 12:10 MLCrane Note Edited: 0040826 View Revisions
2014-06-18 17:33 dregad Note Edited: 0040826 View Revisions
2014-07-07 08:32 dregad Relationship added has duplicate 0008088
2014-07-07 08:33 dregad Note Added: 0040894
2014-07-07 08:35 dregad Changeset attached => MantisBT master 4ef0e69b
2014-07-07 08:35 dregad Assigned To => dregad
2014-07-07 08:35 dregad Status acknowledged => resolved
2014-07-07 08:35 dregad Resolution open => fixed
2014-07-07 08:35 dregad Fixed in Version => 1.3.0-beta.1
2014-07-07 08:51 dregad Target Version => 1.3.0-beta.1
2014-09-09 08:47 dregad Relationship added related to 0017589
2014-12-08 00:34 vboctor Status resolved => closed
2015-05-08 05:00 atrol Relationship added has duplicate 0019699
2016-03-28 11:25 atrol Relationship added has duplicate 0008961