View Issue Details

IDProjectCategoryView StatusLast Update
0014443mantisbtfeaturepublic2014-09-23 18:05
Reporterakocel Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.5 
Target Version1.2.12Fixed in Version1.2.12 
Summary0014443: Status changed to resolved and not to the desired value
Description

When I change a status of a bug with "Change to Status" button, if the new status is higher than bug_resolved_status_threshold, the status is set to "resolved" and not to the desired value.

$g_status_enum_string = '10:open,15:reopen,20:assigned,25:in_progress,30:under_test,35:to_cancel,40:to_confirm,45:to_clarify,47:to_postpone,50:confirmed,55:clarified,70:postponed,80:resolved,82:to_validate,85:canceled,90:closed';

bug_resolved_status_threshold = 80

When I change status from "35:To Cancel" to "85:canceled", the status is forced to "80:resolved"

It is done in bug_update.php :

if ( ( $t_old_bug_status != $t_bug_data->status ) && ( FALSE == $f_update_mode ) ) {
if ( $t_bug_data->status >= $t_resolved
&& $t_bug_data->status < $t_closed
&& $t_old_bug_status < $t_resolved ) {
...
bug_resolve( ... );
...
$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
...
}

Note that the problem doesn't occur if I change the status in the update (edit) page.

TagsNo tags attached.

Relationships

related to 0012097 closedatrol Tracking issue for the refactoring of bug_update.php 
related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

dregad

dregad

2012-07-03 04:56

developer   ~0032225

Last edited: 2012-07-03 04:58

The button wrongly considers any status >= resolved and < closed as resolved. This requires a change in the bug_resolve() function to accomodate for custom status codes between these 2 thresholds.

EDIT: lowered priority/severity as a workaround is available

akocel

akocel

2012-07-03 06:15

reporter   ~0032226

Of which workaround do you speak ?

Change the resolved threshold ?

Why not just call bug_resolve when the new status is equal to bug_resolved_status_threshold ?

In standard solve workflows, you have to pass to this status before change to higher ones, no ?
In my case: resolved => to_validate => closed
When we overpass the resolved step (drop to canceled for example), it is not a "resolve" process.

So to my mind, no need to "resolve" a bug when we change directly to higher status.

dregad

dregad

2012-07-03 06:29

developer   ~0032227

Of which workaround do you speak ?

You found it yourself ==> "Note that the problem doesn't occur if I change the status in the update (edit) page."

In standard solve workflows, you have to pass to this status before change to higher ones, no ?

No you don't have to, it's up to each admin to define their workflow as they see fit, and if it is unrestricted, one can freely go from any status to any other.

Why not just call bug_resolve when the new status is equal to bug_resolved_status_threshold ?

Because as the name implies, it's a threshold not a fixed state value, so we need to check for >=.

In the default workflow, MantisBT does not consider "special" cases like the cancel/validate you have defined. I agree it's a limitation, but unfortunately not one that can easily be overcome.

dregad

dregad

2012-07-03 08:32

developer   ~0032228

I committed a fix for this issue, which is a bit of a hack (modifying bug_resolve() function).

It's worth mentioning that 1.3 is not affected by this issue, as bug_update.php was refactored in that branch some time ago (see 0012097)

grangeway

grangeway

2013-04-05 17:56

reporter   ~0036158

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master-1.2.x 91a99d97

2012-07-03 00:29

dregad


Details Diff
Add param to bug_resolve() to allow "resolution" to custom status

Function bug_resolve() sets the status to bug_resolved_status_threshold.
This behavior is fine with MantisBT's default status enum, but is
causing issues when using a custom target status that is
>= $g_bug_resolved_status_threshold & < $g_bug_closed_status_threshold.

In this case, when changing status using the button on view.php, the
target status selected by the user is overriden by the value of
bug_resolved_status_threshold, resulting in incorrect behavior. The only
way to effectively reach the custom state is by editing the issue.

To address this, a new optional parameter $p_status is added to
bug_resolve(). To make the function call more logical, the signature was
modified: new parameter inserted in 3rd position after $p_resolution.

The function's phpdoc header has been completed.

Fixes 0014443
Affected Issues
0014443
mod - bug_actiongroup.php Diff File
mod - bug_update.php Diff File
mod - core/bug_api.php Diff File