• Icon: Suggestion Suggestion
    • Resolution: Won't Do
    • None
    • None
    • None
    • 1
    • 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.

      Current Behaviour
      Release version and view is associated with only one project.

      Example Scenario
      We are using JIRA to support multiple customers that are using our same product, some of those customers are using the same product version, and therefore are tied to a release cycle for that product version. Under the current implementation I am mapping customer issues to our product release on a JIRA project by project basis. This is fine for a customer-facing view. But there are scenarios where I have implemented a couple JIRA projects for 1 customer to accommodate their workflow. In this 2nd scenario looking at a release on a JIRA project by project basis fails.

      Requested Behaviour
      Allow to view multiple release version under one release view page. We can have this in board's release menu. Customer could define a product version, and under that have various releases versions. Then in any of the JIRA projects they would just tie the project to that product version(s), and thereafter be able to select fix version(s) from the list of releases that exist under that product version.

            [JRASERVER-62015] Release view that span multiple JIRA projects

            Atlassian Update – 8 August 2019

            Hi,

            Thank you for raising this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request.

            This is an automated update triggered by low user engagement with this suggestion (number of votes, number of watchers).

            We hope you will appreciate our candid and transparent communication and our attempts to become more transparent about our priorities. Making tradeoffs and saying no is never an easy task to perform. You can read 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.

            Regards,
            Jira Server and Data Center Product Management

            Gosia Kowalska added a comment - Atlassian Update – 8 August 2019 Hi, Thank you for raising this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request. This is an automated update triggered by low user engagement with this suggestion (number of votes, number of watchers). We hope you will appreciate our candid and transparent communication and our attempts to become more transparent about our priorities. Making tradeoffs and saying no is never an easy task to perform. You can read 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 . Regards, Jira Server and Data Center Product Management

            I would suggest removing releases from being JIRA project dependent. Instead consider to implement releases in a schema format that any JIRA project can subscribe; similar to screens, types, fields, workflow, and security schemas.

            That way a JIRA project can utilise whatever release schema they like. Tickets created in that project will be able to select from the fix version(s), and affects version dropdowns a release number that is from the schema mapped to that JIRA project. In this way we achieve the goal of being able to see various JIRA project tickets within the "Release View" page for a specific release number!

            Stacy Jurke added a comment - I would suggest removing releases from being JIRA project dependent. Instead consider to implement releases in a schema format that any JIRA project can subscribe; similar to screens, types, fields, workflow, and security schemas. That way a JIRA project can utilise whatever release schema they like. Tickets created in that project will be able to select from the fix version(s), and affects version dropdowns a release number that is from the schema mapped to that JIRA project. In this way we achieve the goal of being able to see various JIRA project tickets within the "Release View" page for a specific release number!

              Unassigned Unassigned
              mariffin Mohamed Hazwan Ariffin (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: