View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026990||mantisbt||filters||public||2020-05-28 06:37||2020-08-05 04:56|
|Priority||high||Severity||major||Reproducibility||have not tried|
|Summary||0026990: Changing to a project should reset the projects default filter|
This is one of the most annoying problems. I have with working with mantis with many projects.
What I done:
What I expect:
What I see:
By the way: I have searched if this is a dublicate, but without a more powerful search (like 0026447 :-)), I was overwhelmed.
|Tags||No tags attached.|
This is by design actually.
I understand your point, but in many use cases, returning to the previously used filter is the expected behavior. So I'm not convinced we should change this; at best this could be made configurable behavior.
Also, what exactly do you mean by "clean filter" be ? Equivalent of clicking the reset filter button ?
@dregad, Thanks for commenting.
Yes, the equivalent of "reset filter".
In addition: Is there a way to get a feeling for what would be the better default funktionality? Do you have feedback from user users?
What would be a reasonable expectation? When I change a project, is it more likely that I
From my feeling and working with mantis, everytime I go there, I would like to have a fresh context. In particular, if I chage a project.
What's your experience? Or what would be an approach to find out?
From other software projects I know: It's easy to add options and leave the default behaviour as it is. But this renders into a nightmare of options, in particular some where the impact on the usability is not obivous. At least I hope that in this case the option has to be considered only on one place.
Testing the feature again, that there is a bug with sub-sub projects, that makesbehaviour is inconsistant (on sub-sub projects, filters are set to their parent, but on "All Projects" and sub-projects they are preserved), and probably this is the reason why I find the behaviour particularly annoying.
update: First I thought it was a bug in my local installation, but even when resetting it to the upstream sourcecode version, the behaviour stays the same. I will file a separate bug for this -> 0027129.