Thanks for the script. In my opinion the proper solution is for Mantis to populate the list of users in update as follows:

• Populate all active users that match the required criteria (basically what we have now).

• Add the current user to the list in case it's disabled. This makes sure that the current behaviour where the first user in the list is selected because the current user is not available in the combobox.

If you provide a patch for this, I can integrate it into Mantis 1.1.

Would the following be a proper alternative :

1. Delete user
2. Mantis checks for references to this user
   2a1. If not found, simply delete
   2b1. If found, Mantis asks for replacement user`
   2b2. Replacement user could be defaulted through variable in config_inc
   2b3. If no replacement, No delete, just disable
   2b4. If proper replacement, delete user

I slightly modified cas job to replace entries for user id with drop down lists.
I also provide a patch for adding a submenu for [manage users] menu.
Refer to syncuser modified.zip

Will transfer this one into a plugin for 1.2.0

Attached a plugin to be used as of version 1.2.0

I installed plugin but it doesn't work. When I converge from one user to another I get this message

Database query failed. Error received from database was 0001146: Table 'bugtracker.mantis_project_category_table' doesn't exist for the query: update mantis_project_category_table set user_id=2 where user_id=304.

I will review this plugin over the next few days and provide fix.

Please verify if all fixed in version 0.96

would this work for two user accounts, both with data/issues? ie merge one to another, preserve the others data?

I tried and recieved..

Database query failed. Error received from database was 0001062: Duplicate entry '6-2079' for key 1 for the query: update mantis_project_user_list_table set user_id=2079 where user_id=111

seems I had to remove the sync from user from the project, or else they would conflict after the sync.

@Matthew,
this indeed is a bug. Fixed this in version 0.98.
In principle there is no reason to remove the user. The project_user_list table should only be reviewed by project where it now was updating in one go. This however can lead to upsetting the primary index.

Version 0.98 loaded due to an existing typo. Would appreciate if someone can delete syncuser097.zip

@cas Nice plugin. However, I now have converted my whole history instead of only the assigned to user. I would like to know who entered issues in the past and have the complete history available....is that possible as well?

Could be an option in a next version...........
Is not a difficult change, simply adding Checkbox to convert only issues with a certain status.

Added an option to only convert active issues

@cas That is indeed an improvement. However, active issues should have a remaining history as well. I don't want (e.g.) the reporter to change, only the "assigned to" since I need to know from whom the issue originated and what happened in the meantime....

That status is the most improtant because no-one picks up issues that are assigned to other people...

So that can be achieved relative easy in standard Mantis.
Simply filter this user in the View Issues option
Select all
Assign to someone else
Done !

That is not possible since the user is disabled and therefore not visable in the filter anymore. That means I have to enable him, then filter, reassign and disable again. Fine if it is one user, but we are talking about 50 users...lot of work....

In that case, use the latest version where you can specify alow and a high limit for the status. Issues within the range will be handled.
In your case, simply set both to "assigned"

A, cheers...however:
APPLICATION ERROR 0000401
Database query failed. Error received from database was 0001064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '=> 15' at line 1 for the query: update mantis_bug_tag_table set user_id=264 where user_id=130 and status <= 15 and status => 15.