also Interested !

Interrested too !

Still waiting....

14 years and 650 votes, and still gathering interest for such a basic and common sens requirement ...

Well, it could be worse, licence price could have been multiplied by 4 ...

Please prioritize this issue. It's distracting not particularly for admins, but particularly for all the non-admin users, as they are the ones who can't add new versions.

This is a major compliance issue for our organization requiring extensive workarounds. This is not a bug, this is a missing key feature of the tool. 

I created a post on the Community that provides what I think is all of the necessary information. It's admittedly pretty ugly to look at, but I'd be happy to answer any questions. It requires that you have both Scriptrunner and JSU Automation Suite. I'm running it on Data Center, but I assume that anyone who is looking here is running DC as well.

If you have any questions, put them in the post.

https://community.atlassian.com/t5/Marketplace-Apps-Integrations/Allow-non-admins-to-manage-Versions-Releases-in-Jira-Data-Center/m-p/2472468#M2895

79b0ad2df02c please provide your solution, we already have ScriptRunner, so maybe it's a solution for us.

@Matt Parks I would very much like to see your solution

@matt parks: why don't you share it, so people can decide whether a valid workaround for them or not?

Also: it might give Atlassian some ideas on how to implement....

I mentioned this in an earlier comment but, if anyone is interested, I could share the solution I built that allows users to manage their Versions via a custom issue type and a ScriptRunner script listener.

This seems like a no-brainer. Teams need to manage releases (getting parts of their codebase or software stack to production) and as a system of record they should not be able to do a lot of the other things admins can do.

William above noted that you aren't paying attention to user bases smaller than 5K, cool we have 47K and we're growing. Hopefully that helps with the gathering interest. If I could get everyone to vote on this I would, as it stands they just want me to fix it.

Very dissappointing, spent way too much time finding out that such a basic thing isn't supported!
There is even a plugin that works around this issue, but it so painfully slow: https://marketplace.atlassian.com/apps/1214929/version-manager-for-jira?tab=overview&hosting=datacenter

That plugin however doesn't resolve the issue that my teammates still can't simply add a new fixVersion in the ticket unless I give them project admin rights. So, now they have to go to this plugin page Manage Versions, wait for 10+ seconds for it to load, add new version, then return to the ticket and add it.

I keep getting questions about this and users are amazed that it is not yet implemented.

Dear Atlassian support, thanks to consider this issue seriously instead of letting it in gathering for 13 years. This is a totally a wierd situation for those waiting for such so simple request which will avoid a lot o troubles given full project admin for now to people to change it.

Do you really need help to implement this feature ? if you really need for we have some really good dev in my company if you ae not able to implement such simple thing

So, I thought this issue was only 3 years old from a previous post.  Based on this one, your Customers have been asking for this since 2007.  16 years!....

And reading through the comments, there are even older version going back to 2003..... 20 years to sit on an apparently often asked for features?

What will it take?  Someone getting hired, fix the issue, then quitting?  

It might be kind of a clunky solution, but I worked around this issue by creating a new issue type that hooked into a ScriptRunner listener to create/update/release the versions for individual users. Only users with a particular project role had permission to create this work item, which allows some control over who can manage versions in Jira.

Just want to let you know, that there is a possible solution for you with Version Manager for Jira. Also works fine and is supported for Jira Data Center even though not officially certified.

Best regards
Holger

Need this!!!!

We want lead developers to be able to manage Versions and Components, but not the rest of the project. Please add this feature in the permission schemes. 

Atlassian has stopped caring about customers with less than 5,000 users entirely. As far as I can tell, they have stopped working on anything other than "cloud". And, I'm not entirely certain what they are doing there, because a startling number of these 'defects' from 15 and 20 years past have managed to find their way into cloud. 

Atlassian has grown certain that they are the only game in town, and that everyone is going to use their product regardless, but there are MANY products that are gunning for Atlassian. 

So, hey.. Atlassian! It's time to start acknowledging your customers! Because the MOMENT something else shows up, that is even remotely close to what you can do.. your customers are going to start running like rats on a sinking ship!

I say this, because I truly do love the Atlassian product. Or, I used to. Recently, service and support have largely tanked. But I do want to love again!

Atlassian Customers,

Let's push this through Atlassian support by opening support cases to solve this issue:

https://getsupport.atlassian.com/servicedesk/customer/portal/22 

Don't allow them to close/resolve the case before solving this issue (reopen and escalate until actual solution). This will affect their quality of service metrics and this will add an extra push to implement.

Give it just another 20 years and we will have this very basic feature - looking forward to 2043!

This is the official answer for the support ticket I've opened to Atlassian (names skipped):

"DDD R

02/Dec/21 8:56 PM
Hi Marcos,

My name is XXXX and I’m the product lead for Support here at Atlassian. The support team (JJJ, AAA, and their manager) were diligent and brought this issue to my attention several weeks ago and I personally escalated it. I worked with leadership in both Jira R&D and Jira PM to learn if we could provide a solution to this outstanding issue. The culmination of these meetings was Roman’s post indicating that, given the impact of our existing roadmap, we can’t make progress on this suggestion at this time. We will consider it in the future, but at this time we cannot schedule it. I know this doesn’t help you but rest assured we’ve made every effort in consideration and fully register the challenge brought by your use case, passionate appeal, and disappointment in our decision. This decision was truly hard to make but it was ultimately necessary as the impact of the items on our existing roadmap will have a greater effect. I'm sorry that I don't have better news for you and your team.

Kind regards,

DDD"

"We will consider in the future, but we cannot schedule it" after more than 10 years is a kind of disguise joke. 

Since we can't expect anything from Atlassian in this case, I've started the actions to plan the replacement of Atlassian by other solution inside my company. Am I wrong? 

As it says in the description, this issue here is a replacement for JRASERVER-2743, which in turn was raised 2003.  So this topic is nearing its 20th anniversary. If you add up the votes on all the linked open issues, you get another 556 votes for a total of 999 votes. <IRONY><SARCASM>Atlassian really shows us how "customer centric approach" should be done in product development.</SARCASM></IRONY>.

fully agreed with all marcocssilva says, handling pruduct priority like this when an important security issue is reveal by a lot of users by simply requesting such bug simple thing, its totaly not understandable , but may be atlassain does not care if few customers do ot use theire product because of this ? I wonder how customer feeback and reactivity are scaled in hands of their product manager

Fully desapointed with this feature request created from 2007 ????? and simply answering " thank you for your interrest". Atlassian I you kindding? better says nothing then in such situation which remove all your credibility in such follow up

@Roman Kilosovskiy... sorry... but your comment is a big nothing (to not say something disrespectful).

I'm tracking this issue for years!!! It exists for a long long time...  Take a look:  (8f073317d3ef created issue - 12/Jun/2007 9:08 AM)

How many votes are necessary to be prioritized? Or... How many customers would you loss to understand how this is important?

This is being requested almost for a decade! At least 20 related tickets and probably you missed others, such as: JRACLOUD-67414 As a JIRA administrator, I want a specific set of permissions to see/manage project releases - Create and track feature requests for Atlassian products.)

If a security breach, like this, is your radar, but there are other "outstanding problems" in a top... now I'm really concerned about quality of Atlassian products and about the commitment of their managers and tech leaders... 

THIS IS NOT A "NICE TO HAVE" FEATURE!!! THIS IS A SERIOUS PROBLEM!!! IT'S A BASIC SECURITY RULE MISSING!!Unable to render embedded object: File (  I WOULD TAG IT AS A DEFECT, SEV A) not found.!!

Other thread and a lot of Jira Admins complaining... and detailing how tuff is managing versions using current schema.

Jira - Permissions for Release (atlassian.com)

Also, in the interest of clarity, there is a comment earlier in this thread which cites a potential workaround for this limitation via the use of a third party plugin. Not only this this not a reasonable solution / workaround in my opinion, but it is also not a pragmatic solution either. The plugin mentioned does not support Jira Datacenter nor Jira Cloud, meaning that the only product the plugin can be used against is the now-defunct Server edition.

To be clear, this isn't a "distraction" for Jira admins, it is a security and compliance concern which affects all Jira users. In order for a release manager to do their job in Jira they currently must request full project admin access to be able to manage versions, allowing them access to many other project level features including role management which are not appropriate for their role.

I just want to be sure this feature request is being contextualized properly.

Hi everyone,

Thanks for voting and commenting on this bug. We understand that the current experience is annoying, but unfortunately, we are not prioritizing this bug for our immediate roadmap. There are multiple aspects we need to consider when deciding on which bugs to fix first and improvements to make. We have to make many trade-offs along the way to be sure we are working on the most urgent issues first.

We realise this issue is particularly distracting for JIRA admins. I would like to assure you that we have it on our radar and we will revisit it once we fix other outstanding problems.

I am keeping the issue open so that users can keep voting as we prioritise bugs with high interest in our work. Please watch the issue for further updates.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Roman Kolosovskiy

Jira DC Product Manager

Oh yes please. I currently can't make any of my own release tags and need to bother one of 5 people who may or may not be in or in a meeting etc. This would alleviate a lot of pain for us. 

Could not agree more: the need for release/product managers to become project admin gives them unnecessary abilities -> responsibilities they shouldn't need or have. Please separate the permission to release a version from the rest.

ma.silva we also reported this bug a while back and indeed Atlassian isn't taking this one seriously. And installing a plugin to fix this issue?? Come on....
And what msilberman is stating is even worse; provide a plugin which isn't designed for Data Center.

After 14 years Atlassian can't provide a simple split in permissions

This is a flaw in the security design. The suggested plugin Version Manager for Jira designed for Server ONLY. There needs to be a resolution in the Permissions Scheme which allows us to grant the permissions to someone other than the Project Administrators. The role of managing this is not the admin's role. Please escalate this request. It is not an enhancement.

We have request and report this for a long time already as well and this is part of granularity permission possibility in project and Version management should be one of those granular permission to be added because there is absolutly no sense to give admin rights for managing version which is usually handle by different team and absolutly not the role of a project admin

Atlassian has provided a feedback for this issue... As a customer, I opened a official support request.

It seems Atlassian will not fix this SERIOUS issue.

If you have SEN number, open this issue in a formal way to Atlassian and argue this is not a "simple new feature". It's a REAL and CRITICAL Security breach. It's a DEFECT. 

My workaround in consideration: I'll start to looking for an alternative to Atlassian solutions. The competitors certainly have solutions that implements the BASIC system administration rules and take care of a some-thousand-licenses' customer requests. 

Regards,
Marcos

03/Jun/21 12:33 PM

Hello Team,

Thanks for contacting Atlassian Support!

I'm XXXXXX and I'll assist you in this case.

We believe you may be referring to the suggestion ticket below:

• JRASERVER-12891 - New permissions item - version maintenance (v3)

We have reached out to our project team again to get an update regarding the status of the feature request regarding the ticket above. Our product team has informed us that currently, there's no plan to implement the feature request in JRASERVER-12891.

This was not an easy decision and something that was decided after reviewing our current feature request backlog. We have a set of criteria that we use to decide which feature request that we would like to implement. In case you have missed it, you may take a look at the criteria in the link below:

• Implementation of New Features Policy

Currently, we are focusing on delivering feature requests which bring benefits to a large number of users. We have been working hard to include more new features which are useful for our users and you may view the feature request that we have recently implemented from the Jira Release Notes below:

• Jira Software release notes

We understand that the user interest of feature request in JRASERVER-12891 is relatively high but there are other feature requests which bring benefits for a larger number of users that we are currently working on. We do realize that this feature is something that you would like to see in Jira and rest assured, we are not ruling out of implementing this particular feature request. It's just for now our plate if full with a feature request in our existing roadmap.

We would recommend you to watch the feature request ticket so you can be notified if there are any changes to the feature request. In case you have any additional feedback including how the JRASERVER-12891 will be beneficial for your users, feel free to add a comment in https://jira.atlassian.com/browse/JRASERVER-12891 feature request ticket so our product team better understand users use case scenarios.

 Workaround

As for the workaround, there is a third-party plugin called Version Manager for Jira which might be useful for you. Perhaps you can test it out to see whether it suits your use case.

Please let us know in case of any questions regarding this scenario, then we will be happy to help you further.

Best Regards,
[Remove the engineer name due to privacy aspects] | Atlassian Support Engineer

Yes please, I would be more than happy if this feature is implemented in the server versions.

13 years... And it will never been resolved in Server version... Lets pray for rest of your products

I can only agree that this is a must-have when you use agile boards. 

Lame that this isn't a separate permission.  Release Management teams isn't a new concept....

This functionality is a must-have. Please implement. 

Currently I am not using Jira, but looking at comments after my previous one (and all before it), also number of votes, there is only one word to describe Atlassian's behavior: embarrassing. So many people struggle with this, have to do workarounds and/or introduce security vulnerabilities (by exposing full-admin access in automated processes) because Atlassian IS GATHERING INTEREST FOR 13 FREAKING YEARS. I just cannot understand this, really.

Come on, Atlassian! We don't want to grant users that "Manage Releases" administrative permissions. Please add a proper role for this topic.

We spend several hundred thousand dollars every year in just one of our instances (20k+ users). Yet, we are blockers for not letting a group of users manage their own versions and components. Just as Michelle said, this is just not explainable to anyone that doesn't deal with Atlassian bureaucracy (13 years!) regularly.

This never-ending years-long-loop of not implementing basic (seriously, how architecturally difficult is it to split one permission into three?) features goes directly against one of the company values ("Don’t #@!% the customer").

Is it that you don't have a clear use case for this? I'd offer myself to be interviewed or explain our use case to you if that helps.

we need this as well to implement a new process in our system .

1, we need this issue too. This is not explanable to our users (>4000) 

+1  That is such an essential feature!

I am wondering that this is really questioned

+1

this is ridiculous that such request is on hold for so many years. This is a must have and not only because they might be the number of vote count your are expected but more because a common sense and logic

Please speed it up

regards

+1

This is ridiculous that only the project administrators can manage releases.  Oh well, I guess, I'll just make everybody a project admin.    Half Azzlassian strikes again!

This is causing MAJOR headaches for us, including some security issues that popped up since people who need this right have to have admin rights.  

thumbs up for this issue by me

This feature request is waiting for implementation for almost 13 years! Unbelievable.

+1 from me 

please implement!