0010325: Move should have the option of changing categories - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0010325	mantisbt	bugtracker	public	2009-04-13 07:14	2014-01-21 17:34

Reporter	thraxisp	Assigned To
Priority	normal	Severity	feature	Reproducibility	have not tried
Status	confirmed	Resolution	open
Product Version	1.2.0a3

Summary	0010325: Move should have the option of changing categories
Description	Currently the Move command only changes the project of the issue, leaving the possibility that the category assigned doesn't exist in the new project. In 1.1.6, the category seems to be created in the project. The user should be prompted for the project. An AJAX list would be great.
Tags	No tags attached.

related to	0015230	confirmed		When copying issues, it should be possible to select category to avoid inconsistencies
has duplicate	0005034	closed	vboctor	On move project you can't specify the category you'd like to move to
has duplicate	0006763	closed	vboctor	when try to "move" an issue, only "project" can be changed, however, there is no way to update "category"
has duplicate	0007224	closed	vboctor	"Update issue" and "move" is not good in some casses
related to	0012667	closed	vboctor	Moving issues between projects doesn't update the category
related to	0013233	new		Allow status change upon moving tickets to another project

thraxisp 2009-04-17 22:56 reporter ~0021591	Reminder sent to: jreese It seems that the conversion to category IDs broke the move functionality. It seems that categories are tied to projects now. When the bug is moved, we need to rethink the categories. I'll fix this in the next day or so.

jreese 2009-04-18 11:19 reporter ~0021592	When I made the conversion to IDs, I specifically left the functionality as it currently is because I couldn't think of a "good" method of doing the category change without a major change to the user interface. I decided that it'd be best to, rather than try to have Mantis be overly "clever", just ignore the category issue, and wait for a developer/updater to make an intelligent choice to change the category. However, if you were to succesfully find a way to enhance the move interface to let the user select the new category as part of the move operation, that would be my preferred solution. I just never had the time to implement that myself.

vboctor 2011-01-07 17:55 manager ~0027855 Last edited: 2011-01-07 18:00	I implemented in 0012667 logic to fixup the category automatically as part of the move process (no interactive interface there). However, I think we have the same issue for custom fields, versions, etc. Also user names like reporter / assigned to if they belong to one project but not the other. I wonder if at one point we should implement a compatibility check and only move if that passes. If it doesn't pass, then the user can go and fix the reason. Otherwise, the user can clone or copy and paste into a new issue.

jjenkins 2012-01-20 14:21 reporter ~0030981	Has their been any further progress made with regards to this bug since the last note was added? My organization utilizes MantisBT as part of daily development operations, but this bug in particular is a huge nuisance. When I have to move items, it normally fails and leaves Mantis in a state to where it's almost unusable until I fix the problem. My solution thus far has been to manually edit the database to set the category to match one of the project's categories.

atrol 2012-01-21 02:49 developer ~0030983	it normally fails and leaves Mantis in a state to where it's almost unusable jjenkins, do you use $g_default_category_for_moves which is available since fix of 0012667

atrol 2014-01-21 16:54 developer ~0039127	Unassigned after having been assigned for a long time without progress.

jjenkins 2014-01-21 17:34 reporter ~0039128	atrol, I had not been using $g_default_category_for_moves to work around this issue. I am now, but the original issue persists in the sense that I have to set a default category for each sub project, so not great for maintenance, as I'll have to keep doing this each time we add a new sub project. Regardless, thank you very much for the work-around, as it will prevent the issue from occurring most of the time.