View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010325||mantisbt||bugtracker||public||2009-04-13 07:14||2014-01-21 17:34|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Summary||0010325: Move should have the option of changing categories|
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|
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.
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.
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.
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.
Unassigned after having been assigned for a long time without progress.
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.
|2009-04-13 07:14||thraxisp||New Issue|
|2009-04-13 07:14||thraxisp||Status||new => assigned|
|2009-04-13 07:14||thraxisp||Assigned To||=> thraxisp|
|2009-04-17 22:56||thraxisp||Note Added: 0021591|
|2009-04-18 11:19||jreese||Note Added: 0021592|
|2010-09-29 07:40||atrol||Relationship added||related to 0005034|
|2011-01-07 16:15||atrol||Relationship added||related to 0012667|
|2011-01-07 17:55||vboctor||Note Added: 0027855|
|2011-01-07 17:56||vboctor||Relationship replaced||has duplicate 0005034|
|2011-01-07 17:58||vboctor||Relationship added||has duplicate 0006763|
|2011-01-07 17:59||vboctor||Relationship added||has duplicate 0007224|
|2011-01-07 18:00||vboctor||Note Edited: 0027855||View Revisions|
|2011-09-07 17:08||atrol||Target Version||git trunk => 1.3.0-beta.1|
|2011-09-16 11:03||dregad||Relationship added||related to 0013233|
|2012-01-20 14:21||jjenkins||Note Added: 0030981|
|2012-01-21 02:49||atrol||Note Added: 0030983|
|2012-11-23 09:57||dregad||Relationship added||related to 0015230|
|2014-01-21 16:54||atrol||Note Added: 0039127|
|2014-01-21 16:55||atrol||Assigned To||thraxisp =>|
|2014-01-21 16:55||atrol||Status||assigned => confirmed|
|2014-01-21 16:55||atrol||Target Version||1.3.0-beta.1 =>|
|2014-01-21 17:34||jjenkins||Note Added: 0039128|