Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-67414

As a JIRA administrator, I want a specific set of permissions to see/manage project releases

    • 1,249
    • 42
    • 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.

          [JRACLOUD-67414] As a JIRA administrator, I want a specific set of permissions to see/manage project releases

          Please consider fixing this, it just doesn't make sense the way it is. It's weird that a release master needs admin permissions to set the status of a release.

          Simon Sattes added a comment - Please consider fixing this, it just doesn't make sense the way it is. It's weird that a release master needs admin permissions to set the status of a release.

          Atlassian Update - February 2024

          After some analysis, we've found that this ticket is a duplicate of the request JSWCLOUD-17608 – Add granular permissions relating to version control which has more votes and a recent update from our product team, here.

          We encourage you to watch and vote on the above instead. All internal ticket references on this ticket have been transferred. If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

          Anusha Rutnam added a comment - Atlassian Update - February 2024 After some analysis, we've found that this ticket is a duplicate of the request JSWCLOUD-17608 – Add granular permissions relating to version control which has more votes and a recent update from our product team, here. We encourage you to watch and vote on the above instead. All internal ticket references on this ticket have been transferred. If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

          Will there be an update on including this in the roadmap for 2023?  For minor releases or hot fixes, the speed with which a release needs to be created is critical.  Our Jira admins may be occupied due to the higher level nature of their work and may not be available to create the minor releases. 

          It would also be nice to have the ability to flag a release as major/minor other than by the semantic naming convention.  The next step would be to then provide the ability to restrict by role for creation based on major or minor, so that we could have minor created by developers and major by project admins.  The Approvers option was added but does not resolve this issue.

          Tracy Moffat added a comment - Will there be an update on including this in the roadmap for 2023?  For minor releases or hot fixes, the speed with which a release needs to be created is critical.  Our Jira admins may be occupied due to the higher level nature of their work and may not be available to create the minor releases.  It would also be nice to have the ability to flag a release as major/minor other than by the semantic naming convention.  The next step would be to then provide the ability to restrict by role for creation based on major or minor, so that we could have minor created by developers and major by project admins.  The Approvers option was added but does not resolve this issue.

          Andrew Lam added a comment - - edited

          +1 still waiting for this.

          We want to track our releases in Jira but don't want the devs doing the release to require project admin access to create release versions.
          We currently have to ask our 3 project admins to create a release version then we can add the tickets being released to that version.

          Especially for minor releases, such as releasing a single microservice from Github, we ask for release version to be created and it is not done because of whatever reason (holiday, sickness, busy,...). It is too easy to forget to follow up. Then that release is not tracked in Jira. 

          Andrew Lam added a comment - - edited +1 still waiting for this. We want to track our releases in Jira but don't want the devs doing the release to require project admin access to create release versions. We currently have to ask our 3 project admins to create a release version then we can add the tickets being released to that version. Especially for minor releases, such as releasing a single microservice from Github, we ask for release version to be created and it is not done because of whatever reason (holiday, sickness, busy,...). It is too easy to forget to follow up. Then that release is not tracked in Jira. 

          Tehmina Aslam added a comment - - edited

          How much longer do we anticipate waiting? Is the development of this feature underway, or is it currently under discussion to determine whether it will be addressed or not?

          Tehmina Aslam added a comment - - edited How much longer do we anticipate waiting? Is the development of this feature underway, or is it currently under discussion to determine whether it will be addressed or not?

           Please provide an update on this issue. A lot of customers (who pays) are interested in.

          Juanma López added a comment -  Please provide an update on this issue. A lot of customers (who pays) are interested in.

          Noah Miles added a comment -

          This functionality is critical…. We want to automate the creation of releases, but only want to grant those permissions to automation accounts. We can’t launch that automation while users with rights to add issues to versions still have rights to modify release properties set by automation. This is a huge blocker for us. It is critical certain properties be immutable.

          Noah Miles added a comment - This functionality is critical…. We want to automate the creation of releases, but only want to grant those permissions to automation accounts. We can’t launch that automation while users with rights to add issues to versions still have rights to modify release properties set by automation. This is a huge blocker for us. It is critical certain properties be immutable.

          Elaine Cawthorne added a comment - - edited

          The approver doesn't help me as I need someone to be able to rename the release and release it.  Anyone could add tickets to the release without being an approver

          Elaine Cawthorne added a comment - - edited The approver doesn't help me as I need someone to be able to rename the release and release it.  Anyone could add tickets to the release without being an approver

          @Tracy Moffat - If you're on a bundled release track, it should be coming out in the next release (we are, and I'm seeing it in the list of features to be included in our September release.)

          Esther Strom [ACP-JA] added a comment - @Tracy Moffat - If you're on a bundled release track, it should be coming out in the next release (we are, and I'm seeing it in the list of features to be included in our September release.)

          asimdlv added a comment - - edited

          Hey Tracy Moffat,

          Yea, in our Jira Cloud, when editing a release, we are now able to set "Approver(s)".

          Once these approvers are assigned, they gain the ability to make edits to the release and add related work. They can also update the release's "Approval status," with the default being "Pending." They have the option to choose between "Approved" or "Rejected."

          asimdlv added a comment - - edited Hey Tracy Moffat, Yea, in our Jira Cloud, when editing a release, we are now able to set "Approver(s)". Once these approvers are assigned, they gain the ability to make edits to the release and add related work. They can also update the release's "Approval status," with the default being "Pending." They have the option to choose between "Approved" or "Rejected."

            Unassigned Unassigned
            htemp Heitor T (Inactive)
            Votes:
            1064 Vote for this issue
            Watchers:
            375 Start watching this issue

              Created:
              Updated:
              Resolved: