0019399: Problem when moving issues with category between projects - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0019399	mantisbt	bugtracker	public	2015-02-25 03:48	2016-08-15 09:02

Reporter	krohn	Assigned To	dregad
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	1.2.16
Target Version	1.2.20	Fixed in Version	1.2.20

Summary	0019399: 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).
Tags	No tags attached.

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 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 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 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.

MantisBT: master-1.2.x 8864ef1d 2015-02-25 04:01 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		Affected Issues 0019399
	mod - core/bug_api.php		Diff File
MantisBT: master 93bdaae4 2015-02-25 04:01 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		Affected Issues 0019399
	mod - core/bug_api.php		Diff File