Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-23030

Not equals operator (!=) excludes results with empty values

XMLWordPrintable

    • 57
    • 24
    • Hide
      Atlassian Update – 8 August 2019

      Hi everyone,

      Thanks for sharing your comments and votes on this suggestion. We are sorry to have kept you for quite a while without a clear answer.

      While this suggestion has gathered significant interest, we are not planning to invest in it. That's why we're closing it as 'Won't Do'.

      After careful review of the most pressing needs of our customers, we've decided to prioritize other areas of the Jira Server and Data Center roadmap. Also, in the recent releases we have shipped several highly-voted features and improvements.

      While we understand that current logic for treating EMPTY values may not always be clear, we do our best to describe it in the documentation (NOT IN operator, NOT EQUALS operator). We believe that including EMPTY values is easy when following the docs.

      I understand that our decision may be disappointing, but we also hope that you will appreciate our candid and transparent approach. You can learn more about our approach to highly voted server suggestions here.

      To learn more about our recent investments in Jira Server and Data Center, please check our two new dashboards containing Recently resolved issues and Current work and future plans.

      Kind regards,
      Jira Server Product Management

      Show
      Atlassian Update – 8 August 2019 Hi everyone, Thanks for sharing your comments and votes on this suggestion. We are sorry to have kept you for quite a while without a clear answer. While this suggestion has gathered significant interest, we are not planning to invest in it. That's why we're closing it as 'Won't Do'. After careful review of the most pressing needs of our customers, we've decided to prioritize other areas of the Jira Server and Data Center roadmap. Also, in the recent releases we have shipped several highly-voted features and improvements. While we understand that current logic for treating EMPTY values may not always be clear, we do our best to describe it in the documentation ( NOT IN operator , NOT EQUALS operator ). We believe that including EMPTY values is easy when following the docs. I understand that our decision may be disappointing, but we also hope that you will appreciate our candid and transparent approach. You can learn more about our approach to highly voted server suggestions here . To learn more about our recent investments in Jira Server and Data Center, please check our two new dashboards containing Recently resolved issues and Current work and future plans . Kind regards, Jira Server Product Management
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? 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 , ...)

      Steps to Reproduce

      1. Run a filter similar to the below; 
        assignee != admin
      2. Un-assign one of the issues returned by the filter;
      3. 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

      1. Create a new filter with the below query and give it a name (e.g. Admin's Issues) 
        assignee = admin
      2. Run a search with the below query; 
        filter != "Admin's Issues"

      Testing Notes

      Using Luke to query the Lucene index directly and searching for -color:red you get 70 issues on the use-case presented above (in "Example #1", under "Actual Behavior").

            [JRASERVER-23030] Not equals operator (!=) excludes results with empty values

            Timuçin added a comment - - edited

            The issue: `a=b or a!=b` evaluates to `false`

            Jira response: yeah, we've already told you that when we say equal we mean something else

             

            Let's see what was it that you meant, shall we:

            Advanced searching - operators reference

            The "!=" operator will not match a field that has no value (i.e. a field that is empty). For example, component != fred will only match issues that have a component and the component is not "fred"

             

            So it "will not match" then. Cool, then we should at least be able to use this very easy workaround `NOT component = fred` after all it's simply "not matching", i should be able to just filter the results where it doesn't match `component = fred`, right?

            Wrong. It is evidently and clearly different from "not matching". The expression `component = fred` does not yield `false`, it only evaluates to that later. It's something that both itself and its negated counterpart is `false`. The component is and is not fred at the same time according to this design.

             

            I think Jira is under the impression that this is a debate and having added this as a "design choice" in the docs is winning the argument. I think Jira needs to know that we are not at all interested in a "i said it first" type of justification. If there is a technical necessity like something breaking otherwise, we're all ears. Other than that, we don't care if it's bad coding or bad design.

            This is something you are selling to people. You can make a design choice for a car having the pedals on the passenger seat and include it in the documents, but you can't sell it. No matter how confident you seem telling people to "just get the passenger to use the pedals" as a workaround

            Anyway, I better read the entirety of Jira documentation for any hidden custom definitions for operators. Who knows maybe the `+` operator has an exception too, like if both numbers are prime it multiplies instead of adding. It would technically be a design choice after all. Unless of curse you have another meaning for design choice in the docs

            Timuçin added a comment - - edited The issue: `a=b or a!=b` evaluates to `false` Jira response: yeah, we've already told you that when we say equal we mean something else   Let's see what was it that you meant, shall we: Advanced searching - operators reference The " != " operator will not match a field that has no value (i.e. a field that is empty). For example,  component != fred  will only match issues that have a component  and  the component is not "fred"   So it "will not match" then. Cool, then we should at least be able to use this very easy workaround `NOT component = fred` after all it's simply "not matching", i should be able to just filter the results where it doesn't match `component = fred`, right? Wrong. It is evidently and clearly different from "not matching". The expression `component = fred` does not yield `false`, it only evaluates to that later. It's something that both itself and its negated counterpart is `false`. The component is and is not fred at the same time according to this design.   I think Jira is under the impression that this is a debate and having added this as a "design choice" in the docs is winning the argument. I think Jira needs to know that we are not at all interested in a "i said it first" type of justification. If there is a technical necessity like something breaking otherwise, we're all ears. Other than that, we don't care if it's bad coding or bad design. This is something you are selling to people. You can make a design choice for a car having the pedals on the passenger seat and include it in the documents, but you can't sell it. No matter how confident you seem telling people to "just get the passenger to use the pedals" as a workaround Anyway, I better read the entirety of Jira documentation for any hidden custom definitions for operators. Who knows maybe the `+` operator has an exception too, like if both numbers are prime it multiplies instead of adding. It would technically be a design choice after all. Unless of curse you have another meaning for design choice in the docs

            Timothy Amoah added a comment -

            This is ridiculous  

            Timothy Amoah added a comment - This is ridiculous  

            Taylor Huston added a comment -

            Lol. Just wasted 4 hours of my day trying to figure out why 'priority is not EMPTY' is not the complement of 'priority is EMPTY'. SMH. Ridiculous.

            Taylor Huston added a comment - Lol. Just wasted 4 hours of my day trying to figure out why 'priority is not EMPTY' is not the complement of 'priority is EMPTY'. SMH. Ridiculous.

            Daniela Buffarini added a comment -

            Hello after a big headache, I came to this thread that explains how to really solve this. As my colleagues comment on this "silent" mistake, Jira should address it. Something as key as the operation of operators in large instances of Jira with many users, well, it really should not happen. For my part, I am going to instruct my users about these behaviors but this is only a mitigating factor.

            Daniela Buffarini added a comment - Hello after a big headache, I came to this thread that explains how to really solve this. As my colleagues comment on this "silent" mistake, Jira should address it. Something as key as the operation of operators in large instances of Jira with many users, well, it really should not happen. For my part, I am going to instruct my users about these behaviors but this is only a mitigating factor.

            Meike Pabst added a comment -

            Hi, Jira Server Product Management,

            needless to say, I disagree with your decision, but I realise it's moot to debate you about this if 131 votes weren't enough for you to keep this queued for a fix (especially keeping in mind this is behaviour that likely "silently fails" for a lot of people, they're simply not aware they're getting incomplete results, so they wouldn't think to look for this bug and vote on it - which I hope you've factored into your decision?).

            That said, there are several issues that were combined into this one over time (see "is duplicated by" section), such as the behaviour I commented on, with non-existent fields behaving strangely.

            We believe that including EMPTY values is easy when following the docs.

            Could you tell me if anything has changed that makes my problem go away?

            https://jira.atlassian.com/browse/JRASERVER-23030?focusedCommentId=592680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-592680

            At the moment the workaround requires knowing which projects to exclude, which isn't always feasible in a company with many projects, most of which have a configuration that one isn't familiar with.

            Meike Pabst added a comment - Hi, Jira Server Product Management, needless to say, I disagree with your decision, but I realise it's moot to debate you about this if 131 votes weren't enough for you to keep this queued for a fix (especially keeping in mind this is behaviour that likely "silently fails" for a lot of people, they're simply not aware they're getting incomplete results, so they wouldn't think to look for this bug and vote on it - which I hope you've factored into your decision?). That said, there are several issues that were combined into this one over time (see "is duplicated by" section), such as the behaviour I commented on, with non-existent fields behaving strangely. We believe that including EMPTY values is easy when following the docs. Could you tell me if anything has changed that makes my problem go away? https://jira.atlassian.com/browse/JRASERVER-23030?focusedCommentId=592680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-592680 At the moment the workaround requires knowing which projects to exclude, which isn't always feasible in a company with many projects, most of which have a configuration that one isn't familiar with.

            Domenico Manzo [Actonic] added a comment -

            Hi @all, 

            you may try "Power JQL: extended search functions", this should solve this and other search issues:  https://marketplace.atlassian.com/1216891

            This Plugin give you Additional and useful JQL functions to search issues using the power of regex expressions! 

            Best Regards
            Domenico 

            Domenico Manzo [Actonic] added a comment - Hi @all,  you may try "Power JQL: extended search functions", this should solve this and other search issues:   https://marketplace.atlassian.com/1216891 This Plugin give you Additional and useful JQL functions to search issues using the power of regex expressions!  Best Regards Domenico 

            Kalle Niemitalo added a comment -

            It's also stated that this behaviour is similar in other programing languages - a somewhat vague and weak reason to ignore the issue (which other languages has been asked numerous times - but no answer seems forthcoming).

            XPath 1.0 works the same way; all comparison operators return false when given an empty node-set. https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans

            Kalle Niemitalo added a comment - It's also stated that this behaviour is similar in other programing languages - a somewhat vague and weak reason to ignore the issue (which other languages has been asked numerous times - but no answer seems forthcoming). XPath 1.0 works the same way; all comparison operators return false when given an empty node-set. https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans

            Ben Robinson added a comment -

            I just got done explaining for the umpteenth time, to yet another team manager, why the query "labels = Intuitive" is not the complement of the query "labels != Intuitive".  I let them know about the "set theory snob" at Atlassian. 

            When every single person's intuition is incorrect, maybe it's the product that's incorrect.  I have upvoted this issue.

            Ben Robinson added a comment - I just got done explaining for the umpteenth time, to yet another team manager, why the query "labels = Intuitive" is  not  the complement of the query "labels != Intuitive".  I let them know about the "set theory snob" at Atlassian.  When every single person's intuition is incorrect, maybe it's the product that's incorrect.  I have upvoted this issue.

            Stanton Stevens added a comment -

            It would really be great for Jira to work the way that the users expect it to work here, rather than us have to explain again and again something that is counter-intuitive. Goal: make Jira easy to use!!!

            Stanton Stevens added a comment - It would really be great for Jira to work the way that the users expect it to work here, rather than us have to explain again and again something that is counter-intuitive. Goal: make Jira easy to use!!!

            John M. Black added a comment -

            I don't think we're going to get Atlassian to agree with us here. 

            The coders are designing the UX.  Whenever that is the case, what happens on-screen reflects how they think about bits and bytes, rather than how the rest of humanity thinks about the world. And usually they can't be reasoned with.

            John M. Black added a comment - I don't think we're going to get Atlassian to agree with us here.  The coders are designing the UX.  Whenever that is the case, what happens on-screen reflects how they think about bits and bytes, rather than how the rest of humanity thinks about the world. And usually they can't be reasoned with.

              Unassigned Unassigned
              adc6ee404f6d Jeff Kirby
              Votes:
              131 Vote for this issue
              Watchers:
              103 Start watching this issue

                Created:
                Updated:
                Resolved: