View Issue Details

IDProjectCategoryView StatusLast Update
0004861mantisbtchange logpublic2004-12-11 03:02
Reportercodemastr Assigned Tovboctor  
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.1 
Fixed in Version0.19.2 
Summary0004861: Fixed by user0
Description

Normally, when you resolve a bug, you get a nice msg in the change log showing the title and the username of the person who fixed the bug. However, the username displayed isn't actually the person that fixed it, it is the person the bug was "assigned to." Hence, if the bug was never assigned to anyone, simply changed from "new" to "resolved," this presents a problem where Mantis will display "user0" as the person who fixed it. IMHO, the "assigned to" field should be filled in with the username of the person who closed/resolved the bug so that this problem disappears.

TagsNo tags attached.
Attached Files
4856_4861.diff (3,581 bytes)   
Index: bug_change_status_page.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/bug_change_status_page.php,v
retrieving revision 1.10
diff -u -r1.10 bug_change_status_page.php
--- bug_change_status_page.php	8 Oct 2004 18:57:51 -0000	1.10
+++ bug_change_status_page.php	22 Nov 2004 12:55:05 -0000
@@ -112,7 +112,7 @@
 <!-- Custom Fields -->
 <?php
 $t_custom_status_label = "update"; # default info to check
-if ( ( $f_new_status == config_get( 'bug_resolved_status_threshold' ) ) &&
+if ( ( $f_new_status == $t_resolved ) &&
 			( CLOSED > $f_new_status ) ) {
 	$t_custom_status_label = "resolved";
 }
Index: bug_update.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/bug_update.php,v
retrieving revision 1.77
diff -u -r1.77 bug_update.php
--- bug_update.php	7 Nov 2004 23:18:49 -0000	1.77
+++ bug_update.php	22 Nov 2004 13:10:17 -0000
@@ -74,8 +74,10 @@
 
 	helper_call_custom_function( 'issue_update_validate', array( $f_bug_id, $t_bug_data, $f_bugnote_text ) );
 
+	$t_resolved = config_get( 'bug_resolved_status_threshold' );
+
 	$t_custom_status_label = "update"; # default info to check
-	if ( $t_bug_data->status == config_get( 'bug_resolved_status_threshold' ) ) {
+	if ( $t_bug_data->status == $t_resolved ) {
 		$t_custom_status_label = "resolved";
 	}
 	if ( $t_bug_data->status == CLOSED ) {
@@ -118,7 +120,7 @@
 		# handle status transitions that come from pages other than bug_*update_page.php
 		# this does the minimum to act on the bug and sends a specific message
 		switch ( $t_bug_data->status ) {
-			case config_get( 'bug_resolved_status_threshold' ):
+			case $t_resolved:
 				# bug_resolve updates the status and bugnote and sends message
 				bug_resolve( $f_bug_id, $t_bug_data->resolution, $t_bug_data->fixed_in_version, 
 						$f_bugnote_text, $t_bug_data->duplicate_id, $t_bug_data->handler_id);
@@ -128,6 +130,11 @@
 				if ( $f_close_now ) {
 					bug_set_field( $f_bug_id, 'status', CLOSED );
 				}
+
+				// update bug data with fields that may be updated inside bug_resolve(), otherwise changes will be overwritten
+				// in bug_update() call below.
+				$t_bug_data->handler_id = bug_get_field( $f_bug_id, 'handler_id' );
+				$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
 				break;
 
 			case CLOSED:
@@ -135,14 +142,24 @@
 				bug_close( $f_bug_id, $f_bugnote_text );
 				$t_notify = false;
 				$t_bug_note_set = true;
+
+				// update bug data with fields that may be updated inside bug_resolve(), otherwise changes will be overwritten
+				// in bug_update() call below.
+				$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
+				$t_bug_data->resolution = bug_get_field( $f_bug_id, 'resolution' );
 				break;
 
 			case config_get( 'bug_reopen_status' ):
-				if ( $t_old_bug_status >= config_get( 'bug_resolved_status_threshold' ) ) {
+				if ( $t_old_bug_status >= $t_resolved ) {
 					# bug_reopen updates the status and bugnote and sends message
 					bug_reopen( $f_bug_id, $f_bugnote_text );
 					$t_notify = false;
 					$t_bug_note_set = true;
+
+					// update bug data with fields that may be updated inside bug_resolve(), otherwise changes will be overwritten
+					// in bug_update() call below.
+					$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
+					$t_bug_data->resolution = bug_get_field( $f_bug_id, 'resolution' );
 					break;
 				} # else fall through to default
 		}
4856_4861.diff (3,581 bytes)   

Relationships

related to 0004834 closedvboctor When you reopen an issue (after the issue has been RESOLVED), resolution is not set to REOPENED as it should be 
related to 0004856 closedvboctor Close immediately doesn't 
child of 0004818 closedvboctor Mantis 0.19.2 release 

Activities

vboctor

vboctor

2004-11-15 08:04

manager   ~0008340

This is a bug that seem to be introduced in 0.19.1. The problem is not related to changelog, however, its effect appears in change log. If you look at 0004764 as an example, you will notice that when an unassigned issue was resolved, it got automatically assigned to the user resolving the issue, then it got unassigned again!!!! This is the problem that need to be fixed.

The other fix that need to be done, is that if handler id is 0, then the "(user0)" shouldn't be printed. What happens is that Changelog assumes that all resolved issues have an owner, and doesn't check if the id is not equal to 0.

vboctor

vboctor

2004-11-22 07:22

manager   ~0008389

Fixed in CVS. Also attached patch.