We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-70797

JQL query search using "status was" returns incorrect unreliable results

      Update: April 19, 2024

      Hello everyone! Rene Chiquete from Atlassian Support here.
      After analysis by our development team, it was found that there appear to be 2 scenarios that can lead to the behavior described in this bug report. For one of the scenarios, a process was implemented which can be actioned by us at Support to help solve it. For the other scenario, we will track those cases in this bug report for further analysis.

      In case you are experiencing this behavior: please raise a support request so our team can verify if your case falls under the immediately fixable scenario or the one that requires further analysis.

      Summary

      When searching for issues using a "status" statements ("status was", "status =", "status changed"), the results are unreliable. This happens if there is a Next-gen project in the Jira's Cloud instance.

      Steps to Reproduce

      1. Search for issues using a "status was in/was not in (status1, status2) on date" argument;

      Expected Results

      • All the issues that were on that statuses on that date returns as result of the query.

      Actual Results

      • Some issues show in the result of the query. Other that also matches the argument, don't.

      Update on April the 17th, 2020!

      This problem is very consistent on issues that are imported through a .CSV file and are on a different status than the query.

      Note: the operators AFTER, ON, and DURING are affected by this. It seems BEFORE works correctly.

      Workaround(s)

      Currently there is no known workaround for this behavior. A workaround will be added here when available

      A previous workaround was available, but this no longer works:

        1. JRACLOUD-70797-1.png
          JRACLOUD-70797-1.png
          100 kB
        2. JRACLOUD-70797-2.png
          JRACLOUD-70797-2.png
          151 kB
        3. JRACLOUD-70797-3.png
          JRACLOUD-70797-3.png
          117 kB
        4. JRACLOUD-70797-4.png
          JRACLOUD-70797-4.png
          424 kB

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
            Uploaded image for project: 'Jira Platform Cloud'
            1. Jira Platform Cloud
            2. JRACLOUD-70797

            JQL query search using "status was" returns incorrect unreliable results

                Update: April 19, 2024

                Hello everyone! Rene Chiquete from Atlassian Support here.
                After analysis by our development team, it was found that there appear to be 2 scenarios that can lead to the behavior described in this bug report. For one of the scenarios, a process was implemented which can be actioned by us at Support to help solve it. For the other scenario, we will track those cases in this bug report for further analysis.

                In case you are experiencing this behavior: please raise a support request so our team can verify if your case falls under the immediately fixable scenario or the one that requires further analysis.

                Summary

                When searching for issues using a "status" statements ("status was", "status =", "status changed"), the results are unreliable. This happens if there is a Next-gen project in the Jira's Cloud instance.

                Steps to Reproduce

                1. Search for issues using a "status was in/was not in (status1, status2) on date" argument;

                Expected Results

                • All the issues that were on that statuses on that date returns as result of the query.

                Actual Results

                • Some issues show in the result of the query. Other that also matches the argument, don't.

                Update on April the 17th, 2020!

                This problem is very consistent on issues that are imported through a .CSV file and are on a different status than the query.

                Note: the operators AFTER, ON, and DURING are affected by this. It seems BEFORE works correctly.

                Workaround(s)

                Currently there is no known workaround for this behavior. A workaround will be added here when available

                A previous workaround was available, but this no longer works:

                  1. JRACLOUD-70797-1.png
                    JRACLOUD-70797-1.png
                    100 kB
                  2. JRACLOUD-70797-2.png
                    JRACLOUD-70797-2.png
                    151 kB
                  3. JRACLOUD-70797-3.png
                    JRACLOUD-70797-3.png
                    117 kB
                  4. JRACLOUD-70797-4.png
                    JRACLOUD-70797-4.png
                    424 kB

                        f0f4433adc59 Jędrzej Herbik
                        rgebhardt@atlassian.com Ricardo Gebhardt (Inactive)
                        Votes:
                        34 Vote for this issue
                        Watchers:
                        53 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            f0f4433adc59 Jędrzej Herbik
                            rgebhardt@atlassian.com Ricardo Gebhardt (Inactive)
                            Affected customers:
                            34 This affects my team
                            Watchers:
                            53 Start watching this issue

                              Created:
                              Updated:
                              Resolved: