View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0022412 | mantisbt | filters | public | 2017-02-22 23:16 | 2017-02-23 06:28 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 2.0.0 | ||||
Summary | 0022412: Unassigned issues should filter out resolved issues | ||||
Description | At the moment, the filter only filters out default hide threshold. Should we filter out resolved issues as well? I'm not sure if this is a new behavior or it has been like this for a while. The goal of this filter is to assign issues that need to be resolved, and hence, we should filter out resolved issues IMO. | ||||
Tags | No tags attached. | ||||
+1 |
|
Functionally speaking, I believe it is semantically wrong to have a resolved issue that is not assigned, since by definition someone must have taken care of resolving it, and should therefore have assigned the issue to them. Based on the above, I believe it makes sense not to filter out resolved issues in this case, as it allows to identify (and then correct) the data error. -1 |
|
At the moment we have 2126 unassigned issue. BTW, I am a bit astonished to see that we have 198 closed issues where no one is assigned. |
|
True, but regardless, the "filter" is Unassigned issues, NOT Unassigned issues that are not resolved. The filter should do what it says. Still -1. |
|
which means we should also not filter out default hide threshold |
|
In theory I would say yes, but in this specific case I don't think so, because $g_hide_status_default is a setting which applies globally to the My View page and therefore supersedes the individual filters (except for the Recently Modified (30 days) box, which kind of makes sense but is debatable) . So, not applying that to the Unassigned issues box would introduce an inconsistency vs the other ones. |
|