View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014443 | mantisbt | feature | public | 2012-07-02 12:01 | 2014-09-23 18:05 |
Reporter | akocel | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.5 | ||||
Target Version | 1.2.12 | Fixed in Version | 1.2.12 | ||
Summary | 0014443: 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 ) ) { Note that the problem doesn't occur if I change the status in the update (edit) page. | ||||
Tags | No tags attached. | ||||
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 |
|
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 ? So to my mind, no need to "resolve" a bug when we change directly to higher status. |
|
You found it yourself ==> "Note that the problem doesn't occur if I change the status in the update (edit) page."
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.
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. |
|
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) |
|
Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch |
|
MantisBT: master-1.2.x 91a99d97 2012-07-03 00:29 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 |