View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005466 | mantisbt | bugtracker | public | 2005-04-20 10:08 | 2014-12-08 00:34 |
Reporter | hinke | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.0.0a1 | ||||
Target Version | 1.3.0-beta.1 | Fixed in Version | 1.3.0-beta.1 | ||
Summary | 0005466: 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. | ||||
Tags | No tags attached. | ||||
related to | 0009856 | closed | jreese | Implement method for tracking changes to Description, Steps to Reproduce, and Additional Info |
has duplicate | 0009899 | closed | vboctor | Prevent loss of data during simultaneous updates |
has duplicate | 0008088 | closed | dregad | Data is overwritten by another data when two persons are editing a same issue. |
has duplicate | 0019699 | closed | atrol | MIssing Data Lock on Issue Edit |
has duplicate | 0008961 | closed | atrol | Multiple writing accesses allowed for the same record |
related to | 0017589 | closed | grangeway | "Assign To" does not work on page view.php |
this is called "mid air collision" in BugZilla |
|
John, I can't see how these are related... |
|
@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). |
|
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... |
|
How about:
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). |
|
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? |
|
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. |
|
Any chance to get this little change into one of the next versions? |
|
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... |
|
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. |
|
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! |
|
I marked 0008088 as duplicate. For the record, the discussion there included another patch proposal. |
|
MantisBT: master 4ef0e69b 2014-06-17 07:56 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 |