Hello everyone,

I'm pleased to share we are now exploring this feature, and would love to invite you to take part in an upcoming customer research study!

What’s involved in the research:

Sessions are 50-minutes and conducted over video-conference, so you can participate from anywhere around the globe.

During the research, we'll start with a general chat to get to know you and dive into your use-cases for granular permissions.

As a token of our appreciation, you'll receive an e-gift card worth $100 USD within 5 business days of completing your session.

Interested in taking part? Follow this link to fill in a few more details so we can make sure you’re a good fit.

If you have any other questions at all, feel free to reply to this message or email me directly on adalal@atlassian.com. We look forward to meeting you!

Cheers,

Aditi Dalal
Jira Permissions Team

+1

+1

+1

+1

+1

+1

+1

+1

11 year old feature request? Quality Service Atlassian.
{*}Created: 23/Jul/2013 7:26 PM
{*}+1

Everyone, please vote on the issue counter instead of doing "+1" comments. You are not adding additional weight or priority to this ticket through comments. Also, receiving notifications every time someone posts "+1" comment is quite annoying.

+1

+1

+1

+1

+1

We are integrating with test automation tool, and this is failing.  No matter which role / permission the service account is in, it fails.
This functionality is critical and blocking progress.  

Yes, please this is a must that should be added asap

+1

This should have been a basic feature from day 1, please get it fixed +1

+1 super important!!!

+1, this should be resolved 10 years ago, this is a critical permission that needs to be implemented, we cannot give to all of our team project level admin access...

+1 I was thinking my organization did not setup Jira roles correcty

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.

+1

+1

+1

+1

+1

+1 

+1

This is very important feature for agile teams

+1

+1

+1

+1

+1

+1

+1

How crazy is it that I cannot assign my 2 leads the ability to create a new version without assigning them as admins of the entire project? I can't even go on vacation without getting pinged to create several releases a week. 

This change is a no-brainer. What are we still waiting for??

How many more up votes this request needs? Roughly each vote represents an organization who's struggling to get this implemented.

Please add this

+1

Please, implement separate Version management permission. So many users are interested in this feature.  

Our team also needs engineers to have the permissions to create releases without having full admin permissions on our project. 

Please add this function

It seems not good to share everyone as Admin then just want to release permission !

Exactly! This is not a "desired" feature or a "should/could have". This is a MUST HAVE.

I even disagree with this ticket being a "Suggestion" issue type. This is definitely a design flaw as you don't want a Scrum Master or PO be made an admin of the entire project just so they are able to create Releases.

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.

+1

We have the same need in our team. it will be great to have the option that any team can decide the level of security granularity based on their own Risk assessment.

I agree with all of the above, I keep having to grant Admin access to my team to get around the simplest of issues which really should be permissions based..  This is a really needed feature!!

+1 

This really, really needs to be addressed. 

We should be able to at the very least allocate this permission to a scrum master instead of having to make a user a project admin.

Guys wake up this WONT be patched at all ! EVER !
This ticket is almost 20 YEARS !!
They just don't fucking care, and they won't even address the issue, nor communicate on it..
That's sad but that's the reality. Because Jira is probably one of the biggest leader, they make so much money out of it (cf. licence prices) and have so much customers that they don't care about making them happy. And even worse, it's more profitable for them to leave all the malfunctions and lack of features in Jira because :

• Most people are using Jira for a longtime now and are almost trapped because switching to something else is barely conceivable.
  and
• 3rd party developers, wanting to make money, will develop the most asked features and offer them as paid plugins, so you will pay for it and Jira will have its share on the subscription without having done any work..
  Basically their income increase and they actually need less developers, it's a genius strategy if your only goal is to make money.
  It is definitely a perverse and rotten system.

Without lack of granular control, I had to give admin rights to our scrum master. But unknowingly he screwed up certain project settings. We can't keep a check on what users can do with admin rights at their disposal. This has to be made available at earliest possible

This needs to be implemented ASAP. In 2023 security is King and u cant give users admin rights to mess around with permission schemes and access rights.

I don't think that it has to do anything with difficulty to be honest. As you mentioned - we've seen requests with fewer votes get implemented over the last 10 years. I would add that we've also seen requests with higher level of complexity get implemented which leads me to think there must be another reason.

Perhaps it's time to start working on an open source alternative to Jira or contributing to an existing project. Considering many of Jira users are developers themselves - I can see how loyal Jira users will be excited becoming contributors to a 'Jira alternative' project if it was open source. Just a thought...

We've seen requests with fewer votes get implemented over the last 10 years, so this must be a level of difficulty that precludes implementation. It would be helpful to have an analysis of the request that provides some explanation as to why getting the admin role separated from a release manager role is this difficult. Does Atlassian have their Project Admins managing the deployments and releases in production?