-
Suggestion
-
Resolution: Unresolved
-
167
-
103
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Expected Behavior
The NOT / != operator in a JQL query should return issues with no value set for the searched field or with an empty value.
Actual Behavior
Issues with non-existing or empty values for the searched field are excluded from the search.
Example #1
- I have the below query on a filter, which returns all issues not assigned to the user admin;
assignee != admin
- This filter returns issues assigned to all users but admin, however it doesn't return unassigned
Example #2
- A JIRA instance has 100 issues;
- 90 issues are under a issue type which should have a field named "Color";
- 80 of those issues have a value for the "Color" field;
- 30 of those 80 issues have the color set to "Red";
- The below query returns 50 issues, whereas it should return 70 issues based on the logical value of !=, which is "not equals to", what should imply "empty" or "null";
Color != "Red"
Example #3
- Below query, should returns all issues with fixVersion not equals to 2.
fixVersion not in (2)
- but it doesn't return issues with EMPTY values in fixVersion
- Proper JQL query is, which is not intuitive:
fixVersion not in (2) or fixVersion is EMPTY
- Taking into account that IN is alias to (= OR , ...)
Example #4
- Below query, should return all issues with an empty Epic link.
("Epic Link" is empty or "Epic Link" != <>
- but it doesn't return all the issues with EMPTY values
Steps to Reproduce
- Run a filter similar to the below;
assignee != admin
- Un-assign one of the issues returned by the filter;
- Re-run the search;
Notice the unassigned issue will be now be missing.
Workaround
Create a filter for issues which have a positive match for the value you are trying to exclude.
Example
- Create a new filter with the below query and give it a name (e.g. Admin's Issues)
assignee = admin
- Run a search with the below query;
filter != "Admin's Issues"
Workaround 2
Why my JQL search with “not in” or “!=” (not equals) operators has issues missing
- is duplicated by
-
JRACLOUD-29179 When searching for Issues, negative filtering does not return empty values
-
- Closed
-
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
- relates to
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRACLOUD-23030] Not equals operator (!=) excludes results with empty values in JQL
Please fix this, it's hard to discover bug that creates huge problems if it goes unknown
It seems odd to me that an issue that is unassigned does not get included when a query of 'assignee != myid' is requested. It seems obvious to me that an unassigned issue matches criteria of the issue not being assigned to me. Further, it seems strange that it would 1) not be considered a bug, but rather be a suggestion, and 2) now be 14 years old with no action. Seems like 'Gathering interest' seems to be synonymous with 'Will not fix'.
Just got bit by this issue and spent several hours trying to find my tickets and epics.
Issue has been open since literally 2010; which implies it will never get fixed :/
+1 vote.
Even though I know of this issue, it gets me each time. I just don't make JQL queries that often to remember this behavior.
For a set of 5000 issues with:
- 1000x resolution = empty
- 2000x resolution = done
- 2000x resolution = rejected
JQL results:
- JQL "" gives 5000 records.
- JQL "(resolution = Done)" gives 2000 records.
- JQL "(resolution = Done) OR (resolution != Done)" gives 4000 records. (i.e. 1000 records missing)
We can explain these results because the boolean checks are false for Empty values (...but is still counterintuitive)
But what is even stranger:
- JQL "NOT (resolution != Done)" gives 2000 records.
This should yield 3000 records as the 2000 done issues are excluded from the total set of 5000?
I think I ran into this issue today. I have a != request type and it doesn't list any issues with an empty value for request type.
I was able to confirm this by creating a filter that had my request type and then excluded that filter from the results and now the proper results are displayed.
Crazy this is still an issue.
+1, this has to be a bug, no chance this is intended behavior. So bad!!! This has cost us SO much time and money over the years.