• Icon: Suggestion Suggestion
    • Resolution: Timed out
    • None
    • 0
    • 1
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

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

            [JSWCLOUD-25675] Release view that span multiple JIRA projects

            Atlassian Update - November 1, 2024

            Hi everyone,

            Thank you for bringing this suggestion to our attention. As explained in our new feature policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritise and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.

            Unfortunately, as a result of inactivity for an extended period of time, this suggestion didn’t make it to the roadmap and we are closing it.

            While this issue has been closed, our Product Managers continue to look at requests on jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.

            Thank you again for providing valuable feedback to our team - Jira Cloud Product Management

            Matthew Hunter added a comment - Atlassian Update - November 1, 2024 Hi everyone, Thank you for bringing this suggestion to our attention. As explained in our new feature policy , there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritise and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order. Unfortunately, as a result of inactivity for an extended period of time, this suggestion didn’t make it to the roadmap and we are closing it. While this issue has been closed, our Product Managers continue to look at requests on jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket. Thank you again for providing valuable feedback to our team - Jira Cloud 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:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: