View Issue Details

IDProjectCategoryView StatusLast Update
0010325mantisbtbugtrackerpublic2014-01-21 17:34
Reporterthraxisp Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version1.2.0a3 
Summary0010325: 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.

TagsNo tags attached.


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




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.



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.



2011-01-07 17:55

manager   ~0027855

Last edited: 2011-01-07 18:00

View 2 revisions

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.



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.



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



2014-01-21 16:54

developer   ~0039127

Unassigned after having been assigned for a long time without progress.



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.

Issue History

Date Modified Username Field Change
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