It was with dawning horror that I realized I don't *think* Mantis checks for this:
Alice opens defect 1234 in her browser and starts typing a bug note, and changes the state from FOO to BAR
Simultaneously, Bob opens defect 1234 and starts editing, adding his own bug note but *does not* change the state, leaving it at FOO
While Bob is working, Alice submits her changes (new bugnote, state FOO => BAR).
Then, Bob submits his changes which adds his new bugnote but which *changes the state back to FOO*
I've tested this in 1.0.6 and there does not appear to be any safeguard against it.
[Bugzilla does have this facility, incidentally, in the above scenario Bob would get a warning when he submits that the bug has changed since he started editing and giving him the option to plow ahead and clobber Alice's changes *or* get a new synthesis of his bug and alice's changes and reconcile them.]
Standard apology if this has been asked before but I didn't see it in any of the help or discussion fora and thanks in advance
hmackiernan/SF, CA
Does Mantis detect 'Mid-Air collisions' when 2ppl edit a bug
Moderators: Developer, Contributor
-
- Posts: 18
- Joined: 17 Feb 2006, 19:23
- Location: San Francisco, CA
Problem with simultaneously editing of issues!
Hi,
has anybody found a solution to this issue? I encountered the same problem with simultaneously editing of bugs in Mantis. The system simply overwrites changes without warning.
I already searched the board for a solution but didn't found anything. Hope somebody can help me!
Regards
Patrick
PS: Using Mantis 1.0.1
has anybody found a solution to this issue? I encountered the same problem with simultaneously editing of bugs in Mantis. The system simply overwrites changes without warning.
I already searched the board for a solution but didn't found anything. Hope somebody can help me!
Regards
Patrick
PS: Using Mantis 1.0.1
Mantis doesn't implement optimistic locking or any kind of locking for this scenario. I agree that Mantis should handle this scenario, but so far it wasn't a requested feature.
The solution to this problem would be to update the Issue Update form to send the last modified time to the bug_update.php script. The bug_update.php script should only update the issue if the issue still exists and the last modified time stamp didn't change.
In the case where the issue was deleted or update, an error message should be prompted. The user should be able to go back in order to copy and paste any data that he/she requires to preserve.
I would suggest reporting this issue in the bug tracker. If someone implements it, I would be happy to integrate the patch.
The solution to this problem would be to update the Issue Update form to send the last modified time to the bug_update.php script. The bug_update.php script should only update the issue if the issue still exists and the last modified time stamp didn't change.
In the case where the issue was deleted or update, an error message should be prompted. The user should be able to go back in order to copy and paste any data that he/she requires to preserve.
I would suggest reporting this issue in the bug tracker. If someone implements it, I would be happy to integrate the patch.
-
- Posts: 1
- Joined: 11 Oct 2018, 07:42
Re: Does Mantis detect 'Mid-Air collisions' when 2ppl edit a bug
Hi,
has, in the mean while, some kind of locking been implemented? If so, where can I configure it?
Regards
Bert
has, in the mean while, some kind of locking been implemented? If so, where can I configure it?
Regards
Bert
Re: Does Mantis detect 'Mid-Air collisions' when 2ppl edit a bug
There is no locking implemented, but starting in version 1.3.0 there is some kind of conflict detection.
You will get the following message if there is a conflict.
You will get the following message if there is a conflict.
This issue has been updated by another user. Please return to the issue and submit your changes again.