JQL search using a label

[Mark Thompson]

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)

[Nic Brough -Adaptavist-]

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

and so-on

[Mark Thompson]

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.

[Nic Brough -Adaptavist-]

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.

[Mark Thompson]

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.  

[Nic Brough -Adaptavist-]

The problem is that the implementation is correct and accurate.  Hard for humans to intuit, yes, but it's right.

[Martin Halliday]

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.

[Tony Lacey]

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.

[Amanda Culver]

the query

labels != Group_Testing AND fixVersion = 2016.13

has an implied 'AND labels is not empty'

I'm with Martin, implied behaviour is 'a bad trait in software at all levels'.

[Philip Couling]

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.

[Piyush_Annadate]

This is frustrating for the result.  Atlassian might need to ease this misguided details for Labels in JQL.

[Nic Brough -Adaptavist-]

The behaviour is logically correct and dumbing it down reduces the flexibility of search.

[Philip Couling]

@Nic Brough -Adaptavist- Whether or not it is logically correct depends on your interpretation of what the != operator should mean.  It's logically correct but semantically incorrect. And nobody is talking about dumbing it down! "Fixing" this would NOT reduce the flexibility of searches:

There are two ways you might use the != operator:

1. Search for issues which do not have a specific label excluding those that have no label.
2. Search for issues which do not have a specific label including those that have no label.

Currently for (1) your query needs only the != operator where (2) requires != and a second clause include issues with no label.

If the semantics of != were changed, (1) would be a query using the != and a clause to exclude issues with no label and (2) would just require the !=

There is absolutely no loss of flexibility here. 

The only difference is that the semantics of the != operator will be more inline with the way labels are present in the front-end rather than aligned to the way they are stored in the back end.

[Marie Robinson]

this works for me.  I hide any story with archive as a label but all other stories show whether they have labels or not

labels != archive AND labels is not EMPTY OR labels is EMPTY

[Roger Spooner]

Obviously Jira is not working satisfactorily for users like us (who comment on this thread). This problem has just cost my project a lot in lost issues, because we relied on labels to prioritise work.

It seems to me that the problem is that "labels" is a list of values but the JQL syntax pretends that it is a single value which can match something I specify in a query (labels = special). When we start trying to match any member of a list in my query (labels in (special,boring)) or NOT in my list, it no longer means anything like what it appears to.

To fix this, I think Atlassian needs to extend the JQL syntax to recognise the various operators we need to match a list of labels with a list of queries.

[Nic Brough -Adaptavist-]

There's a whole other conversation to be had about how "using labels to prioritise" is a really terrible idea, especially as Jira deliberately has many better ways to do it.

But I am commenting to question how you think "recognising various operators" would work?  What operators do you think you need and why?

[Roger Spooner]

The operators I would like are something like:

• at least one label needs to be in this list (special, interesting)
• at least one label needs to be the value "special"
• none of the following list may be labels: (irrelevant, boring, obsolete)
• there must not be the label "boring"
• the list of labels must exactly match this list: (special, feasible, releasable)
• all of the following must be labels: (special, feasible, releasable)
• there must be more than 3 labels.
• there must be 0 labels.
• The syntax discussed above about empty lists of labels, and queries for issues where labels cannot exist, should be merged with the negative operators where a label should not exist. i.e. if there are no labels on an issue, then clearly any particular label I maybe interested in is not present.

Jira has other weaknesses about priorities which also need fixing. For example when I sort a table of searched issues by priority, they appear in the order blocker, critical, major, minor, normal, urgent, trivial, undefined. Perhaps it thinks it's an unordered list of enums?

I don't actually use labels as priority rankings. I use them to filter issues that need to be resolved.

[Nic Brough -Adaptavist-]

Those are not search operators, they are usage rules.  Most of which you can already form searches for when you're looking for enforcement.

Additionally, most of the usage you've listed there is not what labels are for.  You should be using the workflow and system fields for most of what you've defined.

I'd suggest revising how you're using Jira, it sounds like you're expecting labels to do a load of stuff that you should be doing with other functions.

[Roger Spooner]

I'm not looking for usage rules to constrain what labels can be entered.

I am looking for issues with those kind of conditions. Sounds like operators to me.

Additionally, I would like that language to be compact and expressive enough to be easy to use.

What is the recommended way to search for issues that do not have a certain label, given the discussions above?

[Nic Brough -Adaptavist-]

But you gave us a list of rules, not searches.

I asked for what operators you think you are missing.

To search for issues that do not have a label, use "labels != <label>"

[Roger Spooner]

This conversation seems to be going backwards. Please help me to help you to improve your product.

The operators I proposed are concrete examples of things I would like to be able to include in a JQL search.

When I search for "labels != <label>" it seems to ignore issues with no labels. As discussed above. This is not the behaviour that the humans mentioned in this thread expected.

[Nic Brough -Adaptavist-]

You did not propose any operators, you gave us a list of rules you might want to impose.

The reason "labels != <label>" ignores unlabelled issues is explained in the previous answers and comments.  If you are interested in unlabelled issues, then add them to the search with "or labels is empty"

[Roger Spooner]

I can see that speaking to you needs to be in the same dialect of JQL that we are discussing. You think it's perfect. It doesn't allow me to express myself.

I will try again. These are conditions I would like to be able to include in a search expression.

• A union B is not empty
• A contains B
• A union B is empty
• A does not contain B
• Set A equals B
• A union B equals B
• Size of set A > N
• Size of set A = 0

I cannot explain any more clearly than all of the contributors have already, that "labels != <label>" should match issues with no labels. Whether your implementation involves empty bags or no bags is firstly an Atlassian implementation detail, and secondly does not change the truth of the operator.

JQL is not serving its purpose properly. You can help make it better. I am trying to help make it better.

[Philip Couling]

.... Nick reading your responses to these comments is extremely frustrating to the point you might be accused of "playing dumb".  Roger Spooner clearly understands the logic you have described.

Roger is highlighting that the "!=" operator fails the Principle of Least Astonishment. This is further evidenced by the fact that you yourself fail to describe its usage without obvious error.  A couple of posts back you wrote:

To search for issues that do not have a label, use "labels != <label>"

This is clearly incorrect, especially given the context of the whole discussion.  "labels !- <label>" does not search for all issues that do not have a specified label because it misses issues that have no label at all. 

If you (even you) can't manage to describe this operator's usage in the context of this discussion then something is plainly wrong with the operator not the users!

I think what Rodger Spooner is trying to say is: if the "!=" operator is so baked in that it cannot be changed then could we at least have some operators that do not fail the Principle of Least Astonishment. 

He's highlighted a very specific reason why these operators fail which is subtly different to the simple lack of matching issues with no labels.  I urge you to re-read his original answer and try to understand what that reason is.  This might help you understand the type of operators he is proposing.

[Nic Brough -Adaptavist-]

Ok, they're still more sets of rules than operators, but they are closer to queries.  Remember that a search is a search for a set of issues, it is NOT the report on what data you get back.

• Label in (A, B)
• Label = B
• Label not in (A, B) or label is empty
• Label != B or label is empty
• Not a query, that's a question to put to what you're processing the results in
• Not a query, that's a question to put to what you're processing the results in
• Not an operator, but look at the results of the search for the size of A to compare with N
• Not an operator, but if a search comes back empty, that tells you you've got a 0 size for A

So, half of your list are already there and the other half are not operators.

>I cannot explain any more clearly than all of the contributors have already, that "labels != <label>" should match issues with no labels.

I cannot explain any more clearly than I did before why this is technically wrong, as it would stop some valid searches working.

[Nic Brough -Adaptavist-]

@Philip Couling- apologies, our postings crossed over, so my last comment was written before I'd seen what you've said.

I completely agree that "labels != something" fails the principle of least astonishment.

Unfortunately, there's a lot of logic that does.  Humans are notoriously bad at logic, and clarity, especially when using fuzzy languages, and we're even worse when negatives are thrown into a question. 

That's no excuse for pandering to it though.

The answer to "what colour is Wednesday?" is different to "does wednesday have a colour, and if so, what is it?". 

[Roger Spooner]

The syntax of set operators like "Label = B" is misleading. It contains hidden logic about "any one of the labels so long as there is at least on".

The syntax of "Label != B or label is empty" is over complicated, as discussed.

You mention what I'm processing the results in. I want to see the resulting issues in the Issue Search list, from where I may perform actions on them. I suppose other users might be writing scripts but I'm not. So I don't see how I can be presented with a list of issues matching the second half of my requirements.

Can we have an operator that properly represents "issue does not have label B" ? I do not understand why users should have to face the ugly implementation details. Surely the answer to "is Wednesday green" is no.

After that new operator, there's the retraining to explain to users and their hard-coded queries how we got in to this mess.

[Philip Couling]

Once again.  Humans are fuzzy thinkers, and that includes Atlassian developers (no insult intended). This isn't about pandering to bad logic.  It absolutely isn't about that.  This isn't about logically correct or logically incorrect JQL.

The problem here is that the data-model and the front-end present a different model of this information.  Through using the front end user will naturally expect the data model to represent an issue with no labels as the empty set, not null.

Is the user right to expect this?  Well in most software contexts the definition of "null" is loosely described as "unknown", "not set", "not defined"; although philosophers define many (>20) possible definitions of null.  Atlassian's decision at some point was to mark an issue with no labels with null.  But this decision is very surprising.  An issue with no labels does not have undefined labels... it has no labels. IE: it has the empty set of labels.  That is it is the data model that is logically incorrect not the JQL.

So this brings us to the question of why Atlassian chose to use null and not the empty set.  I personally can't see a good reason for it.  It's a logically incorrect representation (in my view). 

So is this all logically correct? @Nic Brough -Adaptavist-  If you can show some solid reasoning why null is logically the right representation of no lables in the data-model, then your assertion that this is all "locally correct" might stand.  But without that your assertion is fundamentally flawed.

Ultimately one other question is whether or not you are going to inflict your underlying data model on users (some argue this to be a cruel and unusual punishment for any software) or if you are going to make JQL follow the model as presented in the font end.

In conclusion there is absolutely nothing logically incorrect about interpreting no labels as the empty set.  This is not about pandering to bad logic or fuzzy thinking!

[Nic Brough -Adaptavist-]

Yes, it is "misleading", for humans who make incorrect logical assumptions.  It's natural, it's how we think, even those of us who have a lot of experience and try to think logically fall back on fuzzy logic by default. 

But it's still correct.  And changing it to meet our failures is not useful.  In fact, it would be a terrible thing to do for many people.  First, you lose or dumb-down the preciseness of the search, and secondly, you'll find people who are absolutely gobsmacked that anyone would even be having this discussion, because to them, it's perfectly clear that you have to have a value to compare against when you're saying "not that value".

That's where "is wednesday green" comes from - it's a brilliant example of why you have to be precise with logic and hence why != is working correctly.

Think through the answers to that question.  There are broadly four possible answers to it that people might give you, and of those four, the only incorrect one is "no".

As for

> can we have an operator that simplifies the question "issue does not have label B"?

I'm completely with you.  There isn't one, but I think there should be.

It is a different question to "label on an issue is not B" which is what = and != ask about, but it's a perfectly good question, probably more useful, definitely more clear than = and != and I think we should have it.  I don't have a good idea of how to phrase it in a way that would make people reach for it instead of !=, but I'd still love to have one.

[Nic Brough -Adaptavist-]

@Philip Couling- Since when was null = 0? 

"Labels do not apply here" is not the same as "There are 0 labels applied to me"

Have a think through the question "is Wednesday green?" - hopefully that will help you understand it.  You'll need to work through all four possible answer categories to get there.  I'd also recommend reading up on the mathematics (and boolean logic) around the theories of the number 0.

[Philip Couling]

@Nic Brough -Adaptavist- 

Getting warmer but we're still a long way off.

How and were is this concept "labels don't apply" ever presented in the UI? Be careful.  This is "labels do not apply" not "there are no labels that apply".  The two phrases are semantically very different.

There is no presentation of the "labels don't apply" concept ever in the UI (correct me if I'm wrong).

If this is truly a thing, and it is legitimately useful then why is there no "labels do not apply" check box in the UI?  This would give the user the opportunity to switch between null and empty set in the datamodel.

How would the "labels don't apply" concept ever be practically useful?  I've worked as a software engineer for many years and still can't think of one.

In fact the current UI just says "no labels" under the Labels header.  At least this should be replaced with "labels don't apply" in the UI.

[Roger Spooner]

Wednesday is not green. If we want a boolean answer, it's False. I really don't understand why there's a problem here.

While we're here, null = 0 in most programming languages and that history affects most of us.

As @Philip Couling says, the list of labels is presented like an empty set in the UI, which is what I'm working with. In that sense the user experience is poor.

But beyond that, the syntax around "=" and "!=" suggests that these are single valued. The syntax is misleading and unconventional.

[Philip Couling]

@Nic Brough -Adaptavist- So now you have presented a new concept: "Labels do not apply" (as distinct from "there are not Labels that apply").

You want to tell us that this concept is really a concept in Jira, but it isn't presented as one to the user - ever (correct me if I'm wrong).

• There is no "Labels do not apply" check box (that would theoretically give the user the ability to chose between null and empty set in the data model).
• On an issue, under the Labels header it says "No Labels" not "Labels don't apply" and these mean very different things!
• If this were really a deliberate concept then why has it been implemented at the exclusion of of representing an issue for which Labels applied, yet none have been assigned.

It feels like you're inventing concepts / features on the hoof to justify current behaviour.  Maybe I missed something obvious in the UI.

In practice, if you were to implement such a feature you would:

1. both present it properly in the UI and you would (on most cases)
2. give it it's own (boolean) field in the data-model.
3. not implement it at the exclusion of the empty set

You already can search for issues with no labels so it's not even clear why this would be a useful feature.

[Nic Brough -Adaptavist-]

Ok, two more essays that show a lack of understanding miss the point.  Let's get back to the basics.

>Wednesday is not green. If we want a boolean answer, it's False.

That is only one of the four answers, but you've also changed the question by phrasing it that way.

To show that you're understanding the underlying logic of this, can you please give me the four possible categories of answer to  "Is Wednesday green"?  Ideally with the explanation of why "no" is a summary of the one category that is always going to be wrong.

>While we're here, null = 0 in most programming languages

Oh hell no it's not.  If you truly think that, at that level of simplicity, please, rethink.  If you would like to qualify that with "meaning that some weakly structured languages assume an equivalence, relying on the coder to know and deal with that", that's right.  But again, fuzzy language.  Null is not 0 and by definition they are not the same thing.  Two cats live with me now.  If one of them dies or leaves, I have one cat.  If the last cat dies or leaves, I don't have a cat shaped boson star or black hole in my house, I have zero cats.  Two very very different things.

[Mark Thompson]

It's the != and Not In items that are not working.  I can do a search of labels = Group_Testing AND fixVersion = 2016.13 which returns 12 issues.  You would think changing = to != or Not in would then remove those 12 items and leave the remaining 23 but it does not.

[Jobin Kuruvilla [Adaptavist]]

Ah. As Nic mentioned, you need to also search for issues that doesn't have a label. "!=" searches for issues with labels, but not matching to given label, only.

[Jobin Kuruvilla [Adaptavist]]

Why do you think it is not working? Are there other issues with label "Group_Testing" with fixVersion as "2016.13"?

Looks like there is only one issue satisfying both conditions?