View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0023384 | mantisbt | other | public | 2017-09-21 10:59 | 2017-10-06 16:59 |
Reporter | helfy022 | Assigned To | atrol | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | won't fix | ||
Product Version | 2.5.1 | ||||
Summary | 0023384: deprecated Status options appear in filter list | ||||
Description | Hello, In our configuration, we have sought to hide the "acknowledged" and "confirmed" Status options:
Furthermore, with respect to existing bugs, statuses of "30" or "40" in the mantis_bug_table were updated to be "50." The updates successfully and consistently show the pared down list in the report and view bug pages. One strange issue, though, is that the deprecated options are temporarily visible in the Filters list for status. Before clicking on the Status filter link, one can see the deprecated "30" and "40" options (see the filterStart.PNG upload). After clicking the Status link, the finalized list noted earlier is seen (see the filterClick.PNG upload). What causes this behavior, and what can be done to ensure that the hidden "30" and "40" options are never seen (even temporarily)? Thanks, | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
I was not able to reproduce the issue using the given information. Do you see the wrong status values when entering the page without clicking on Do you get the problem after restarting your web server and after clearing browser cache and cookies? |
|
Hi Atrol, The circumstances seem to be unique to a particular project, and the problem would only be visible when navigating to the View Issues page and NOT clicking on the Status link. After clearing the browser cache/cookies, the Status for the project in question was not laid out as had been done before, and clicking on Status showed the expected list of options. Perhaps the cache/cookies clearing will need to be recommended to users before rolling this out to everyone. As an aside, under what circumstances will View Issues show the options for a filter without clicking on it (as opposed to it just being "[any]")? Thanks, |
|
By the way, I did also notice that "resolved" and "closed" were missing in the filterStart.PNG screen shot (i.e., when I had first navigated to the View Issues page), but found that they were there after clicking on the Status link. Again, after clearing the cache/cookies, that list was not visible when first navigating to the View Issues page (and only "[any]" is shown under "Status" before clicking on that filter link). Thanks, |
|
Whenever you return to "View Issues" page, Mantis restores the last filter you had set for the current project. You will get the same problem if you choose a stored a filter which contains status values that no longer exist. It would not be easy (maybe even not possible) to invalidate / repair any filter settings automatically whenever someone changes any of the configuration values. |
|
Hi Atrol, Sounds good. Many thanks for the note about stored filters. It'll be important to notify folks about the possible implication on those when we roll this out. Looking in the mantis_filters_table table, it appears that filters are stored as strings, so converting there will not be straightforward. I'm also curious how those stored filters will respond when these status options are updated. I'm really glad you've pointed this out so that the implications will be understood ahead of time. Thanks again, |
|
Cleaning the filter selected values from non-existant ones before showing them in the filter dialog may be a way to avoid the presentation issue. And the filter would be saved more cleanly when updated. However, the user have a deeper problem, if there is data already referencing those values: bug status, history table for status changes, etc. |
|