View Issue Details

IDProjectCategoryView StatusLast Update
0023384mantisbtotherpublic2017-10-06 16:59
Reporterhelfy022 Assigned Toatrol  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionwon't fix 
Product Version2.5.1 
Summary0023384: deprecated Status options appear in filter list
Description

Hello,

In our configuration, we have sought to hide the "acknowledged" and "confirmed" Status options:

  • custom config updates:

    # Status enumeration updates
    # $g_status_enum_string = '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved,90:closed';
    $g_status_enum_string = '10:new,20:reopened,50:assigned,80:resolved,90:closed';
  • custom string updates:

    # $s_status_enum_string = '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved,90:closed';
    $s_status_enum_string = '10:new,20:reopened,50:assigned,80:resolved,90:closed';

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,
Ryan.

TagsNo tags attached.
Attached Files
filterStart.PNG (24,390 bytes)   
filterStart.PNG (24,390 bytes)   
filterClick.PNG (26,187 bytes)   
filterClick.PNG (26,187 bytes)   

Activities

atrol

atrol

2017-09-21 11:27

developer   ~0057776

I was not able to reproduce the issue using the given information.
Quite strange, not sure you noticed that your 2nd screen shot does not show resolved and closed.

Do you see the wrong status values when entering the page without clicking on Status?

Do you get the problem after restarting your web server and after clearing browser cache and cookies?

helfy022

helfy022

2017-09-21 11:44

reporter   ~0057778

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,
Ryan.

helfy022

helfy022

2017-09-21 11:46

reporter   ~0057779

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,
Ryan.

atrol

atrol

2017-09-21 14:35

developer   ~0057785

Whenever you return to "View Issues" page, Mantis restores the last filter you had set for the current project.
In your case, it's been a filter where you had set status values new, reopened, acknowledged(30), confirmed(40) and assigned.
30 and 40 are displayed as there are no longer status values available after your changes of $g_status_enum_string

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.
That's why I am resolving the issue as won't fix

helfy022

helfy022

2017-09-21 14:46

reporter   ~0057786

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,
Ryan.

cproensa

cproensa

2017-09-25 07:14

developer   ~0057805

It would not be easy (maybe even not possible) to invalidate / repair any filter settings automatically whenever someone changes any of the configuration values.

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.