In fact, there's a pretty simple solution that can be implemented:

• Add a field to the bug table which is the modification token. This can be an incrementing integer or a random integer or string or whatever. Point is just that for each modification, the field's contents changes.

• Send the modification token to the browser in the bug edit form. When the user submits their changes, the modification token comes back to the server.

• If the modification token received from the browser is the same as the modification token currently in the bug table, the edit is accepted and recorded in the bug table, and the modification token is updated (either incremented, or another random value is stored there).

• If the modification token received from the browser is different from the modification token currently in the bug table, then someone else has modified the bug already, and the user should be informed of this and asked to redo their changes.

FileMaker Pro has this (it's called the mod_id there). Wikipedia and probably other wiki systems have this. It's a good idea.

Another solution:

Using the mantis_tokens_table or similar table, add a type for TOKEN_ISSUE_LOCK.

Then when a user goes into the bug update form, add a row to the table with the 'timestamp' being when they started editing, the 'expiry' set to when their exclusive update rights end, and 'value' set to the issue id.
When the user's update of the issue is complete, the token is deleted.

If second user attempts to go into the bug update form for an issue already "locked", they will get a message stating who is already updating that issue.

If the first user never completes the update before the "expiry" time, the second user is allowed to update the issue and the first user will then have to re-submit their changes. This would be accomplished by the second user's update removing the first user's token when their token is added to the token table.

The 'expiry' value should be calculated from something defined in the config_defaults_inc.php file as 30 min. or 1 hour. that way it is configurable.

I'm aware of this issue and the method I had in mind for fixing it is what ryandesign suggested with "last modified" field as the token. Last modified is currently updated when an issue is updated or its related data like notes are changed. Although this may cause more conflict than what is abosuletely necessary, I don't think the conflict will happen often enough to justify an extra field.

There is also a benefit from disallowing two users to add notes in parallel, is that the 2nd user should ideally take the note of the first user in consideration before submitting their notes.

So adding notes / updating issue header information / and potentionally other operations can all be guarded by the issue last modified timestamp.

My suggestion helps to resolve conflict between two users working on the same issue while minimizing users having to re-enter their work, and lets the second user know someone is already working on the issue.

The only additional field would be for the timeout value, and could just be hard-coded if necessary.

I had the same problem in my team.
My solution is attached as zip including 3 files:

• bug_unlock.php
  --> This is a new file needed to force an unlock on a bug.
• bug_update.php.diff
  --> Unified diff file. I'm not quite sure if the diff info fits to actual mantis release, so just add the block directly under following lines

  Update the bug entry, notify if we haven't done so already

  $t_bug_data->update( true, ( false == $t_notify ) );

• bug_update_advanced_page.php.diff
  --> same issue... Just add the first block directly under the line print_recently_visited();
  And the second block somewhere in the form.

Additionaly you need 2 new rows in mantis_bug_table:
locked_since int(11)
locked_by text

That's all. Maybe this patch will appear in next mantis release ;-)

additional functions for bug_api.php:
/**

• locks the bug
• @param int p_bug_id integer representing bug ids
• @param user user who wants to lock the bug
• @return bool (always true)
• @access public

• @uses database_api.php
  */
  function bug_lock( $p_bug_id, $user_name, $time_stamp ) {

  $t_bug_table = db_get_table( 'mantis_bug_table' );

  $query = "UPDATE $t_bug_table
  SET locked_by=\"" . $user_name ."\",
  locked_since=$time_stamp
  WHERE id=$p_bug_id";

  db_query_bound( $query );

  return true;
  }

/**

• unlocks the bug
• @param int p_bug_id integer representing bug ids
• @return bool (always true)
• @access public

• @uses database_api.php
  */
  function bug_unlock( $p_bug_id ) {

  $t_bug_table = db_get_table( 'mantis_bug_table' );

  $query = "UPDATE $t_bug_table
  SET locked_by=\"\",
  locked_since=0
  WHERE id=$p_bug_id";

  db_query_bound( $query );

  return true;
  }