View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016054 | mantisbt | bugtracker | public | 2013-06-13 12:32 | 2017-05-28 08:12 |
Reporter | dregad | Assigned To | |||
Priority | normal | Severity | tweak | Reproducibility | N/A |
Status | new | Resolution | open | ||
Summary | 0016054: Refactoring the notion of "fixed issue" | ||||
Description | Currently, an issue is considered as "fixed" if its resolution code is >= $g_bug_resolution_fixed_threshold and < $g_bug_resolution_not_fixed_threshold Considering the way the resolution enum is currently defined, it leaves 'reopened' status in a kind of weird state as it's considered fixed by the above definition. | ||||
Additional Information | As suggested by atrol in 0015653:0037182, the 2 thresholds config could be replaced by a new one, an array of resolutions to be considered as "fixed". | ||||
Tags | No tags attached. | ||||
Must be careful with bug_actiongroup_page.php and bug_change_status_page.php, as these rely on $g_bug_resolution_fixed_threshold not as a threshold, but as a default value for the selection list. Must find a way to define that default (maybe using the array's 1st element). |
|
Was also my 1st thought, but having also an UI for the configuration would mean that you have to offer an option for reordering the values. So maybe something like $g_bug_default_resolution_fixed is easier to implement. |
|
To add to this issue: Is it correct to have "resolution" values that represent a non-resolution? Note "bug_resolved_status_threshold": |
|