View Issue Details

IDProjectCategoryView StatusLast Update
0019399mantisbtbugtrackerpublic2016-08-15 09:02
ReporterkrohnAssigned Todregad 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.16 
Target Version1.2.20Fixed in Version1.2.20 
Summary0019399: Problem when moving issues with category between projects
Description

When moving an issue from a project to another, and the issue-categeory does not exists in target-project, you see an error and can not access the issue any more.

Steps To Reproduce
  • Have project X with a category "CAT-1"
  • Have project Y without categories.
  • Add an issue in project X, assign it to category "CAT-1"
  • Move die issue from project X to project Y
  • "Error: 1502 Category not found" when accessing Bug and on "overview" (maybe in all lists where the category is show next to the issue).
  • Issue is not editable any more, so you can not remove the category afterwards and have to edit directly in database (table mantis_bug_table).
TagsNo tags attached.

Activities

dregad

dregad

2015-02-25 04:01

developer   ~0048891

Hello,

Did you read this ?
http://mantisbt.org/docs/master-1.2.x/en/administration_guide/admin.troubleshooting.html#ADMIN.TROUBLESHOOTING.ERRORS.1502

krohn

krohn

2015-02-25 04:30

reporter   ~0048892

Hello,
thanks for the hint.

If understand right, $g_default_category_for_moves has to be set to a defined category to prevent this problem.

But our target-project no categories (We do not even have the id 1, "General"). Am I forced to create a dummy-category for all projects or is it valid to set $g_default_category_for_moves to false or 0, in order to remove the category while moving it from project x to project y?

krohn

krohn

2015-02-25 05:49

reporter   ~0048893

Ok '$g_default_category_for_moves = 0;' helps. This issue can be closed.

Maybe $g_default_category_for_moves=0 would be a better default value?

dregad

dregad

2015-02-25 09:53

developer   ~0048894

I think the case of the target project not having any categories (I assume you set allow_no_category = ON here) was not fully considered/tested.

That being said, as you found out Mantis will assign category 0 (i.e. "No Category") if you set $g_default_category_for_moves = 0.

However, I did a quick test and noticed that this only works if the setting is set globally (i.e. in config_inc.php or as an "All Projects" configuration), otherwise Mantis assigns the original category ID, leading to the error you reported.

I believe this is a bug, and will submit a fix for that later on.

That being said, FYI since 1.2.18 Mantis no longer throws an error in the case of an invalid category, and displays it as @<category_id>@ instead. I suggest you upgrade to the latest version.

Maybe $g_default_category_for_moves=0 would be a better default value?

Not good for the "standard" situation where category is mandatory.

Related Changesets

MantisBT: master-1.2.x 8864ef1d

2015-02-25 09:01:28

dregad

Details Diff
Use default category of target project when moving issues

When moving an issue having a given category to another project where
said issue does not exist, Mantis sets the issue's category according to
$g_default_category_for_moves.

However, bug_move() retrieved this setting in the context of the issue's
"old" project which is incorrect when the default category is different
in the target project (i.e. project-specific settings via Manage Config
page).

Fixes 0019399
mod - core/bug_api.php Diff File

MantisBT: master 93bdaae4

2015-02-25 09:01:28

dregad

Details Diff
Use default category of target project when moving issues

When moving an issue having a given category to another project where
said issue does not exist, Mantis sets the issue's category according to
$g_default_category_for_moves.

However, bug_move() retrieved this setting in the context of the issue's
"old" project which is incorrect when the default category is different
in the target project (i.e. project-specific settings via Manage Config
page).

Fixes 0019399
mod - core/bug_api.php Diff File

Issue History

Date Modified Username Field Change
2015-02-25 03:48 krohn New Issue
2015-02-25 04:01 dregad Status new => feedback
2015-02-25 04:01 dregad Note Added: 0048891
2015-02-25 04:30 krohn Note Added: 0048892
2015-02-25 04:30 krohn Status feedback => new
2015-02-25 05:49 krohn Note Added: 0048893
2015-02-25 09:53 dregad Note Added: 0048894
2015-02-25 09:53 dregad Assigned To => dregad
2015-02-25 09:53 dregad Status new => assigned
2015-02-25 09:56 dregad Changeset attached => MantisBT master-1.2.x 8864ef1d
2015-02-25 09:56 dregad Status assigned => resolved
2015-02-25 09:56 dregad Resolution open => fixed
2015-02-25 09:56 dregad Fixed in Version => 1.2.20
2015-02-25 09:56 dregad Changeset attached => MantisBT master 93bdaae4
2015-02-25 09:57 dregad Target Version => 1.2.20
2015-03-02 08:03 vitsaadmin Issue cloned: 0019414
2016-08-15 09:02 dregad Status resolved => closed