This is a very simple query that just doesn't seem to work in Jira. Any help as to why these searches would not return a complete list would be appreciated.
I've used the following two queries and they work fine by selecting items from a list:
labels != Group_Testing - returns hundreds of issues
fixVersion = 2016.13 - returns 30+ issues
The following queries all return a single issue:
labels != Group_Testing AND fixVersion = 2016.13
fixVersion = 2016.13 AND labels != Group_Testing
fixVersion = "2016.13" AND (labels not in(Group_Testing))
fixVersion = 2016.13 AND labels not in (Group_Testing)
fixVersion = 2016.13 AND labels !~ Group_Testing (Not supported which is kind of annoying)
I think this is down to the difference between "label is not" and "label is empty".
When an issue has no labels, it does not pass the test "label is not", because there's nothing to compare. I answered a question that was similar earlier, and blamed human language structures - most of our languages are unclear on the difference between null, empty and filled, and they discourage us from being clear enough for the computers to understand us.
The short version - try adding "labels is empty" to the "nots".
(labels != Group_Testing OR labels is empty) AND fixVersion = 2016.13
(fixVersion = 2016.13 OR labels is empty) AND labels != Group_Testing
This is a horrible implementation. labels != Group_Testing should return anything that doesn't have a group testing label
(labels != Group_Testing OR labels is empty) AND fixVersion = 2016.13 will return more results but will not return all results.
Let us just say I have multiple labels (which I do). I'd have to do the following query
(labels != Group_Testing OR labels is empty OR labels = projectx OR labels = projecty) AND fixVersion = 2016.13
This may get a few more issues but not all the issues. Lets say a project doesn't have a label field in the JIRA implementation. The fix version can be found but "labels is empty" won't return project tickets that don't have a label field. I think I'm in trouble because I don't see a way to add "field doesn't exist" to my query. It's what I'm stuck with. I'll probably have to add the label field to all instances. I still think the JIRA implementation of this search is painful at best.
It's not the implementation, it's the problem that humans are fuzzy thinkers. Fuzzy thinking is imaginative, creative and inventive. But it's unclear and imprecise, and utterly useless for computers.
You're assuming you don't need to explain the exact query to the computer, but computers can't read your mind (yet). So you need to be precise.
The implementation does work for "field does not exist". That is not quite technically the same as "field has nothing in it", but the result does work. "is empty" will fetch both "empty" and "field isn't even there" results.
I thank you for the first answer but really? You can call the sky green all you like but if it looks blue to me than it's blue....8-) is empty is not gathering "field isn't there" for me. Every bug that doesn't display for me is missing the label field in the field configuration. All the items with a label field work fine with the != and is empty query. There may be another term besides is empty that might find it but is empty is not working for our configuration.
I think the problem here is that computer programmers are very literal and precise and describe this behaviour as "correct" from that standpoint, but any person who is not a computer programmer would say that this behaviour is very surprising.
Surprising is an extremely bad trait in software at all levels.
As a software developer myself, I see this implementation as poor. I cannot see the benefit in differentiating between a list of labels that is empty and a non-existent list. This isn't reflected in the interface which indicates either None or shows a list of labels. It doesn't remove the Labels label to indicate that the labels list no longer exists. I would prefer that a boolean test on labels behave as though a non-existent list and an empty list are the same.
Nick is wrong to suggest this implementation is correct. I agree humans are fuzzy thinkers. Developers are human too.
It's such a common mistake... to believe that null and empty are the same concept. They are not. Just as "my bag is empty" is not the same as "I have no bag".
This leads to a design decision between null, empty, both or neither. Too often the decision between them is put down to (misguided?) performance considerations without taking into account expected behaviour.
The way labels are presented to the user is as a set of labels. The vast majority of users will interpret the absence of any label as the empty set, NOT the absence of a set entirely. The implementation should not have used null to represent the empty set.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG