I can't find any option for this. My team cannot manage releases unless they're an admin. This is ridiculous, SURELY Atlassian have a setting for this somewhere that I'm missing....?
Hi Allan,
You must be a Project Administrator to do a release on a board. But you don't have to be a Jira Systems Administrator.
Why on earth do we not have the ability to grant this permission without granting project administrator status. It should be its own setting.Ridiculous product development decisions.
Well, I think it's an appropriate place to put something that allows cards to be removed from boards and "archived" to an effect. But curious as to where you think it would be appropriate. Why would an entire role be created just do a release on a board? Who would you imagine doing that who wouldn't already be a project administrator.
Not trying to be argumentative - just interested in the thought process.
Managing entire project setting and performing release is totally different thing. Imagine release task that after resolving the a release on a board, the person would create tag in their repository (i.e. release on a board is part of release flow), but who is not necessary to have modifying the all Jira setting in the project.
You should be aware of there are the same demands - https://community.atlassian.com/t5/Jira-questions/Jira-Permissions-for-Release/qaq-p/596027
i find myself on this page in 2022, with the exact same feedback as those above. A project administrator should be able to grant access to devs etc to determine releases as they see fit. This is a shortfall of the tool, and a large inconvenience to the team managed project model
I also find myself on this page in 2022 and I agree there should at least be an option in the scheme to give another role the ability to do this.
I have just encountered the same problem and found this chat. It is a MUST that the release rights can be given to the developers independently of the project administrator, wherever. Is there an initiative to make this possible?
We're struggling with this as well. From a security standpoint, it is frankly unacceptable that these permissions are tied to being a Project administrator.
Atlassian takes the Oprah approach.
YOU GET PROJECT ADMIN RIGHTS
I guess nobody at Atlassian has heard of the principle of least privilege.
We use one project for app environment consisting of more then 50 app while bussines requirements can go through multiple apps. We have sometimes up to 20 releases in month.
Every project member must be able to start its own release. So with the current limited possibilities of the JIRA, everyone must be a project admin...
We are not happy about it. Believe me.
Agreed this is still a big problem for us.
i have no obligation but to add "+1" for these features,
we are supported by external and can't give them project admin access just to add the release version.
we need separate permission attribute for release version.
[JRACLOUD-34015] Separate Project permissions for Version Management - Create and track feature requests for Atlassian products. vote for this feature to be add!
My company has same problem. This is very unconmfortable. There are working projects over 50. This tool makes us to assign some managers to register version names...
voted!
already 744 votes and 287 watches, how many will jira team consider this feature and move from the GATHERING INTEREST state?
[JRACLOUD-34015] Separate Project permissions for Version Management - Create and track feature requests for Atlassian products.
Seems like the simplest solution for access and rights problems is to grant admin rights to everyone and just fix the mistakes after.
I hope our future admin army does not figure out the delete button.
Indeed, I upvote the need to be able to assign users to add and complete releases without having to make them project administrators. I spend 30 precious minutes trying to figure it out to no avail and yet when you search it says is 'resolved'. I was so excited ...
The original Answer is only partially correct (at least for Data Center). Until Atlassian deigns to add this as a stand-alone permission, you need the following permissions on your project to fully manage Releases & Versions:
1. You must have the Administer Projects permission (with or without extended project administration). NOTE: This permission alone allows you to CREATE a Release AND add issues from the backlog to a version. It DOES NOT allow you to add an issue to a version in a Detail screen (neither the board Issue Detail View, the Edit dialog nor the Detail screen)
2. You must have the Resolve Issues permission. This will enable you to add an issue to a Version using the board Issue Detail View, the Edit dialog and the Detail screen.
For us this was critical as we often add issues after they are In Progress (no longer in the backlog.
Hope this helps clarify this rather confusing problem.
Same issue as others on here who want a secure, least privileged, environment. We NEED (not want), the ability to have true granular control over permissions. Someone should NOT have to be an admin of an entire project in order to create releases. This also allows them to do many other things within the project settings, including adding new users to the project. We have a strict access request process to protect data that Jira isn't allowing us to abide by due to this issue.
One year later.
one of the product managers asked to have permission for creating releases in his group project. Cited he has been doing this in our previous system for years.
Yep, moving to Jira feels like a downgrade on every single aspect.
@Martin Matloha How do you manage at the end?
We've given up, and broadly assigned limited Project Admin and Resolve Issues permissions to all teammembers, POs and SMs
I can't help but ask why everyone on a team would need to create or manage releases? Atlassian has spent decades working with hundreds of thousands of the largest organizations in the world. From my personal experience most requests or custom work is because of an issue in process and a perceived need... to make things easier for you, short term.
No, not everyone should be a project admin just like not everyone should be creating or altering release versions.
If you run one large monolithic project for many apps/services/teams perhaps reevaluate that approach to narrow the scope of admin rights.
Gathering inters is only for people to complain, Atlassian hasn't decided anything based on that information for the last 20 years
It looks like you're new here. Sign in or register to get started.
