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

List Issues in Issue Navigator according to FixVersions regardless of Issue Key

    • 4
    • 2
    • 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.

      Problem Definition
      Currently in JIRA if users list issues according to the FixVersions, JIRA will be listing the Issues according to the Issue Key and after that according to FixVersions value. This is because versions are project specific and the sort order is defined by the arrangement of the project versions within the project configuration.

      Suggested Solution
      Allow users to sort issues by Fix Versions value even though they are searching for issues from multiple projects.

      Workaround
      Currently there's no workaround for this.

          Form Name

            [JRASERVER-59992] List Issues in Issue Navigator according to FixVersions regardless of Issue Key

            Benny added a comment -

            Facing the same issue, the filter with multiple projects when try to order by FixVersion does not work, and I cannot use this in two dimensional graph. It is a common and normal thinking for most people that when we say "sort by FixVersion" then it should simply sort by FixVersion, not implicitly including the issuekey hidden behind the sorting logic.

            Hope this can be fixed asap.

            Benny added a comment - Facing the same issue, the filter with multiple projects when try to order by FixVersion does not work, and I cannot use this in two dimensional graph. It is a common and normal thinking for most people that when we say "sort by FixVersion" then it should simply sort by FixVersion, not implicitly including the issuekey hidden behind the sorting logic. Hope this can be fixed asap.

            This becomes an issue on the Train/Program level.  I experience the same issue with multiple projects that use the same FixVersion value in the Two Dimensional Gadget in Jira Dashboards.  For example, I see multiple FixVersions where I have project and FixVersion fields in the axes.  Instead of one value for "2021.06.30" with numbers by project, I have "2021.06.30" listed many times.  This makes seeing a quick total by FixVersion or going to the sub-filter via pivot link impossible. 

            Please fix.

            Victoria McLean-Wilkerson added a comment - This becomes an issue on the Train/Program level.  I experience the same issue with multiple projects that use the same FixVersion value in the Two Dimensional Gadget in Jira Dashboards.  For example, I see multiple FixVersions where I have project and FixVersion fields in the axes.  Instead of one value for "2021.06.30" with numbers by project, I have "2021.06.30" listed many times.  This makes seeing a quick total by FixVersion or going to the sub-filter via pivot link impossible.  Please fix.

            Betty Lipic added a comment - - edited

            yes correct i am getting this issue with multiple projects in JQL.. i am using the Two Dimensional Gadget on the dashboard and spotted it... however it comes from the query not the gadget - they are all in seperate projects - there should only be 1 row for R1.9.1 and one for R1.9.01 but they appear for each project

            Betty Lipic added a comment - - edited yes correct i am getting this issue with multiple projects in JQL.. i am using the Two Dimensional Gadget on the dashboard and spotted it... however it comes from the query not the gadget - they are all in seperate projects - there should only be 1 row for R1.9.1 and one for R1.9.01 but they appear for each project

            Eshwar R added a comment -

            This seems to be an issue even when we create cross project release versions from Portfolio. Ex: There are 5 project spaces in a portfolio plan and we create a cross project release version say "2021 Mock Release". Each project space reflects this fix version in their respective space and also are able to tag issues to it. But when we query for all 5 projects to list count of issues resolved per fix version , then the cross project fix version repeats for each project. In this case you see 5 rows of 2021 Mock Release, one for each project space and just a simple single row called 2021 Mock Release with the total issue count across all project space.

            Eshwar R added a comment - This seems to be an issue even when we create cross project release versions from Portfolio. Ex: There are 5 project spaces in a portfolio plan and we create a cross project release version say "2021 Mock Release". Each project space reflects this fix version in their respective space and also are able to tag issues to it. But when we query for all 5 projects to list count of issues resolved per fix version , then the cross project fix version repeats for each project. In this case you see 5 rows of 2021 Mock Release, one for each project space and just a simple single row called 2021 Mock Release with the total issue count across all project space.

            Steve added a comment -

            These are all good suggestions, but the main issue is that we have multiple projects that get released on the same schedule, for example the 2nd Friday of every month.  So what I need is to be able to sort these Jiras by the release version to understand what is going in with that release.  It makes no sense to circumvent the sort request to insert the issue key prior to the requested sort order.  It should be based upon the sort order that I choose alone.

            Steve added a comment - These are all good suggestions, but the main issue is that we have multiple projects that get released on the same schedule, for example the 2nd Friday of every month.  So what I need is to be able to sort these Jiras by the release version to understand what is going in with that release.  It makes no sense to circumvent the sort request to insert the issue key prior to the requested sort order.  It should be based upon the sort order that I choose alone.

            It would be logical to allow a sorting based on the release / start date of each version reather then the actuall name 

            Boris Vereertbrugghen added a comment - It would be logical to allow a sorting based on the release / start date of each version reather then the actuall name 

            This suggestion seems to rely on the fact that your Version/s are 'global' rather than 'local' to a project, which cannot be assumed. We have different products in different projects that depend on each other but have completely different Releases/Versions. For instance, PROD_A version 6.8 may include PROD_ALL_REST_API version 4.11.

            For what you seem to be using this for, would using Component/s be a better option?

            Another option could be to add a new (System?) field 'Version_Name' and be able to form a JQL with an ORDER BY Version_Name. You could probably create a Live Field yourself if you have the appropriate App (add-on) - "Power Scripts™ for Jira". This does not cover the use case of multiple FixVersion/s very well, however.

            Sten Sundelin added a comment - This suggestion seems to rely on the fact that your Version/s are 'global' rather than 'local' to a project, which cannot be assumed. We have different products in different projects that depend on each other but have completely different Releases/Versions. For instance, PROD_A version 6.8 may include PROD_ALL_REST_API version 4.11. For what you seem to be using this for, would using Component/s be a better option? Another option could be to add a new (System?) field 'Version_Name' and be able to form a JQL with an ORDER BY Version_Name. You could probably create a Live Field yourself if you have the appropriate App (add-on) - "Power Scripts™ for Jira". This does not cover the use case of multiple FixVersion/s very well, however.

              Unassigned Unassigned
              vshanmugam Vicknesh Shanmugam (Inactive)
              Votes:
              135 Vote for this issue
              Watchers:
              49 Start watching this issue

                Created:
                Updated: