View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009139 | mantisbt | bugtracker | public | 2008-05-12 00:49 | 2018-05-01 00:28 |
Reporter | lgsolano | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Summary | 0009139: resolution values dont depend on status values. they should | ||||
Description | as of 1.1.1 resolutions have no workflow. resolution changes should be conditioned by status changes. | ||||
Tags | mantishub | ||||
related to | 0016054 | new | Refactoring the notion of "fixed issue" | |
has duplicate | 0016793 | closed | atrol | Resolution should be dependent on Status |
has duplicate | 0008940 | closed | atrol | Some resolutions shouldn't be available when status is set to Closed |
has duplicate | 0005686 | closed | atrol | Resolutions of OPEN and REOPENED should not be allowed when resolving or closing an issue. |
has duplicate | 0023510 | closed | atrol | resolution field |
It seems that a relationship between status and resolution fields already exists. Our testing shows that in some cases 'invalid' resolution and status return error number 24. So this issue seems like a bug rather than a feature request. According to our testing, when manually editing the issue details and attempting to change the status or resolution fields to a 'dis-allowed' combination the error is returned and also when using the change status button and actively changing the status (i.e. not leaving the defaulted setting) the error is returned. However, when using the change status button and leaving the defaulted resolution value, it does not check for a valid resolution. The expectation is that 'open' or 're-openned' status should return an error when in resolved or closed state. All other resolution values are only compatible with 'resolved' or 'closed' and should return an error. |
|