View Issue Details

IDProjectCategoryView StatusLast Update
0004834mantisbtbugtrackerpublic2004-12-11 03:02
Reporterpacketeer Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.1 
Fixed in Version0.19.2 
Summary0004834: When you reopen an issue (after the issue has been RESOLVED), resolution is not set to REOPENED as it should be
Description

When you reopen an issue (after the issue has been RESOLVED), resolution is not set to REOPENED as it should be. In fact if you look in the Issue History, the resolution at reopen is set to REOPENED and then immediately set back to its previous value.

To repeat the problem, resolve an issue with a resolution (e.g. fixed), close and then reopen it with a new assigned person. The issue resolution doesn't change to "reopened".

The problem is due to a bug in bug_update.php. When an issue is reopened, function bug_reopen is firstly called which sets resolution to REOPENED. Then few lines of code down, function bug_update is called to update other fields such as AssignedTo etc... Unfortunately, function bug_update resets resolution from REOPENED to whatever its original value was.

The fix is to add a line of code $t_bug_data->resolution = config_get( 'bug_reopen_resolution');
to the block of code in the program bug_update.php that deals with reopening.

This will make sure that REOPENED resolution doesn't get reset by mistake.

                    .........
                    case config_get( 'bug_reopen_status' ):
                            if ( $t_old_bug_status >= config_get( 'bug_resolved_status_threshold' ) ) {
                                    # 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;
                                    $t_bug_data->resolution = config_get( 'bug_reopen_resolution');   # fix
                                    break;
                            } # else fall through to default

                    .....etc....
Additional Information

This bug is introduced in 19.1. It used to work fine in 19.0

TagsNo tags attached.

Relationships

related to 0004856 closedvboctor Close immediately doesn't 
related to 0004861 closedvboctor Fixed by user0 
child of 0004818 closedvboctor Mantis 0.19.2 release 

Activities

vboctor

vboctor

2004-11-22 08:07

manager   ~0008393

Fixed in CVS. See also patch attached to 4856 if you need to fix it in 0.19.1.

Issue History

Date Modified Username Field Change
2004-11-08 18:50 packeteer New Issue
2004-11-22 08:05 vboctor Relationship added related to 0004856
2004-11-22 08:05 vboctor Relationship added related to 0004861
2004-11-22 08:06 vboctor Assigned To => vboctor
2004-11-22 08:07 vboctor Status new => resolved
2004-11-22 08:07 vboctor Fixed in Version => 0.19.2
2004-11-22 08:07 vboctor Resolution open => fixed
2004-11-22 08:07 vboctor Note Added: 0008393
2004-11-22 08:09 vboctor Relationship added child of 0004818
2004-12-11 03:02 vboctor Status resolved => closed