0009831: Wrong status is used for Reopen Status - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0009831	mantisbt	bugtracker	public	2008-11-17 23:34	2009-01-15 11:25

Reporter	olegos	Assigned To	jreese
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	1.2.0a2
Target Version	1.2.0a3	Fixed in Version	1.2.0a3

Summary	0009831: Wrong status is used for Reopen Status
Description	I have All Project's Reopen Status set to Acknowledged, and Test project's one set to New. When reopening a bug in the Test project, if I have All Projects selected (in the Project selection box), the bug goes to Acknowledged. If the Test project is selected, it goes to New. Issue's project should always be used to get the Reopen Status, not the user's current project.
Tags	No tags attached.
Attached Files	bug9831.patch (1,129 bytes) --- html_api.php.orig 2009-01-07 03:05:50.000000000 -0600 +++ html_api.php 2009-01-13 14:26:13.727409986 -0600 @@ -1274,10 +1274,11 @@ # Print a button to reopen the given bug function html_button_bug_reopen( $p_bug_id ) { $t_status = bug_get_field( $p_bug_id, 'status' ); - $t_reopen_status = config_get( 'bug_reopen_status' ); $t_project = bug_get_field( $p_bug_id, 'project_id' ); + $t_reopen_status = config_get( 'bug_reopen_status', null, null, $t_project ); - if( access_has_bug_level( config_get( 'reopen_bug_threshold' ), $p_bug_id ) \|\| (( bug_get_field( $p_bug_id, 'reporter_id' ) == auth_get_current_user_id() ) && ( ON == config_get( 'allow_reporter_reopen' ) ) ) ) { + if( access_has_bug_level( config_get( 'reopen_bug_threshold', null, null, $t_project ), $p_bug_id ) \|\| + (( bug_get_field( $p_bug_id, 'reporter_id' ) == auth_get_current_user_id() ) && ( ON == config_get( 'allow_reporter_reopen', null, null, $t_project ) ) ) ) { html_button( 'bug_change_status_page.php', lang_get( 'reopen_bug_button' ), array( 'bug_id' => $p_bug_id, 'new_status' => $t_reopen_status, 'reopen_flag' => ON ) ); } } bug9831.patch (1,129 bytes) bug9831_2.patch (950 bytes) --- bug_view_page.php.orig 2009-01-07 03:05:48.000000000 -0600 +++ bug_view_page.php 2009-01-13 18:43:34.637407111 -0600 @@ -50,6 +50,7 @@ # in case the current project is not the same project of the bug we are viewing... # ... override the current project. This to avoid problems with categories and handlers lists etc. $g_project_override = $t_bug->project_id; + unset($g_cache_config_project); } if ( ADVANCED_ONLY == config_get( 'show_view' ) ) { --- bug_view_advanced_page.php.orig 2009-01-07 03:05:48.000000000 -0600 +++ bug_view_advanced_page.php 2009-01-13 18:43:57.147407015 -0600 @@ -49,6 +49,7 @@ # in case the current project is not the same project of the bug we are viewing... # ... override the current project. This to avoid problems with categories and handlers lists etc. $g_project_override = $t_bug->project_id; + unset($g_cache_config_project); } if ( SIMPLE_ONLY == config_get( 'show_view' ) ) { bug9831_2.patch (950 bytes)

olegos 2009-01-13 15:34 reporter ~0020613	Attached is a patch against git trunk for fixing this particular issue. Am I correct in thinking that all other calls to config_get() in html_api.php that don't pass the fourth argument, in functions that take bug_id, should be similarly modified? Seems to me that a lot of other stuff is similarly broken... Should I submit a patch for the rest?

olegos 2009-01-13 18:26 reporter ~0020616 Last edited: 2009-01-13 19:51	Oh, my head hurts. I've discovered $g_project_override which is I think how bug's project was intended to be used instead of the current project. So my patch is wrong. The real problem then seems to me to be in config_api.php, this code in config_get(): prepare the projects list $t_projects = array(); if(( null === $p_project ) ) { if( !isset( $g_cache_config_project ) ) { $t_projects[] = auth_is_user_authenticated() ? helper_get_current_project() : ALL_PROJECTS; (that helper_get_current_project() call returns $g_project_override if set) But the problem is that by the time bug_view_page.php sets $g_project_override, $g_cache_config_project is already set (it gets set at the very top with config_get( 'core_path' ) ), and is always going to be used by the code above, instead of the new value of $g_project_override. I'm not sure how to properly fix this.

olegos 2009-01-13 19:58 reporter ~0020617 Last edited: 2009-01-13 20:24	OK, my next attempt at fixing this is in the attached bug9831_2.patch. Is this the right way to do it? It seems kludgy. There are MANY other pages that need similar fixing. In some places (e.g. bug_actiongroup.php), config_flush_cache() is called after setting $g_project_override, but config_flush_cache() doesn't flush $g_cache_config_project. Maybe it needs to, and it should be called everywhere, since cached config items may depend on the current project?

jreese 2009-01-14 18:20 reporter ~0020624	Targetting for 1.2.0a3 release.

jreese 2009-01-15 10:50 reporter ~0020629	Fix committed to 1.2.x development tree.