When kind of query would break simple filters for sprint boards?

[Randy]

Hi Everyone,

We have some users who are using quick filters. All was fine until recently when they hit the following issue.

As an example, we have quick filter "A" defined as "Custom Select Field" != "XYZ" and quick filter "B" defined as being "component not in (some.component)".

When using quick filter "A" or "B" by themselves, they are fine. However, when using them additively / together, the query doesn't work.

Or as one quick filter named "C" made up of ""Custom Select Field" != "XYZ"  AND "component not in (some.component)" it still doesn't work.

I've read a couple threads on this board mentioning quick filters being "intended for simple cases".

What is considered a simple query and causes quick filters to break? Is multiple negations considered complex? I know @Matt Doar had mentioned this in another post.

Thanks in advance for your input.

[Nic Brough -Adaptavist- · Accepted solution]

That should be working.  However, I suspect you may have run into a logical quick that's counter-intuitive (it's correct behaviour, but humans don't think the same way)

Try changing filter B to

component not in (some.component) or component is empty

[Randy]

Thanks @Nic Brough -Adaptavist-  for the quick response. Sorry for the additional question as I may not be seeing it quite yet.

When you say ...

"component not in (some.component) or component is empty" 

Why the "or component is empty"?

The assumption is that as long as it is not in that component (or some.component) in this case, it should be valid. Component being empty opens up another avenue?

[Nic Brough -Adaptavist-]

Because "not in component" logically implies that there is a component to look at.  When there isn't one, there is no useful answer to the question, so logic ignores it.

So, when you're looking for "not something that can be described as X", you need to say what the "not X" is and also include "there's nothing to look for".  Humans make this logical jump all the time (which can have some interesting failures when they make that assumption), but you need to spell it out in logic.

[Randy]

Thanks for that detailed explanation Nic. Will try that out.

[Randy]

Actually sorry one question more. If it works fine by itself right now as a single simple filter, why would it be showing any different when AND-ed with another simple filter?

I will try the above however to see if there is a difference in the multiple simple filter cases.

[Matt Doar]

If you have ScriptRunner and run the JQL as a search, then there is a little icon near the search magnifying glass. It will tell you how the JQL was converted into a Lucene query. Sometimes that helps me to understand why a query is not working as expected.

p.s. do you have a link to what I said before?

[Randy]

Thanks @Matt Doar for the rapid response. Will look into that as well as we do have ScriptRunner.

But how is quick filter more restricted? It sounded like quick filters can't handle regular JQL queries or am I mistaken?

Here is the link to your previous response.

https://community.atlassian.com/t5/Jira-questions/Additive-Quick-Filters/qaq-p/1603

Where you made the following comment.

"Quick Filters are intended for simple cases. For more complex searches, including OR, use the regular JQL Basic or Advanced search for issues."

Thanks!