Allow "Inversion" of Quick Filters so they could effectively "add" rather than remove issues.
We need to use quick transformation filters that behave as if they are connected with an "OR" instead of an "AND" clause. I realize doing that would be problematic, but there would be a simple workaround if it were possible to merely invert the effect of selecting the filter buttons. Specifically, when the button is deselected (the default state) the filter would be applied, and when selected the filter would be deactivated.
This could be implemented by providing a single checkbox in the edit screen for a quick filter that inverts the effect of the filter. So instead of not showing non-matching items, selecting the button would now show non-matching items. This may sound confusing at first, but only the creators of the filter buttons need to understand the logic. Most users would just see a button that says "include x" or something to that extent and know that selecting it shows "x" which was filtered out by default.
When such a filter is created, it would be written according to its default (button deselected) behavior so that it filters out the items that selecting the button are intended to show. However, it should be named according to its deactivated (button selected) behavior so that users know its effect is to include rather than hide certain items.
As an example, let's say that I have a number of possible statuses for each issue, and I want buttons for each status that when selected show all issues having that status. As it stands, the only options are (1) have the buttons filter out every other status besides the desired one or (2) design the buttons to hide all issues with a given status. The obvious problem with (1) is that selecting more than one button returns nothing. The problem with (2) is that it is cumbersome to select every single status that one wishes to hide, just to show one or two of them.
If it were possible to simply invert the effect of the "hide" buttons in method (2), then by default (when deselected) these filters would all be active, showing none of those statuses. The buttons would obviously be renamed as "show x" rather than "hide" so users know to select the desired subset of statuses, instead of the undesired subset.
thank you for your request! please check the comment
-
AdminJulia (Product Owner, ALM Works) commented
Hello Seth,
Thank you for your suggestion! In your example with statuses, did you tried to use "not in" jql function? (https://confluence.atlassian.com/jirasoftwareserver/advanced-searching-keywords-reference-939938744.html#Advancedsearching-keywordsreference-NOTNOT)
We will think about solving it on our side, but the jql solution is the most flexible one, I'd say.
Thanks again!Julia,
ALM Works team.