Same here - I need to give project admins the ability to create workflows for their own project without exposing all of the work that we do within JIRA!

Yes, I would like to know the same because we're using the Server version. 

That blog entry makes a point of saying "On the Jira Cloud team, we’re working hard to change this."

Does it apply to the server too?

Has this Jira ticket for the server been superseded by https://jira.atlassian.com/browse/JRASERVER-65574. I imagine some of the 1500 votes here would apply there – it only has 52 votes so far.

Hi,

I just released a plugin to delegate group management to empowered users in your instance. You can give it a try here: https://marketplace.atlassian.com/plugins/com.caritteprod.group-ambassadors/server/overview

This is just a part of your request but I'm sure it would help!

As it's a new plugin, I'm really interesting in gathering feedback to improve in the near future. Keep me posted if you like it!

Cheers

Hi everyone,

Thanks again for all your votes and comments on this suggestion.

In JIRA platform 7.3, we allowed project administrators to edit their project's workflows under specific conditions. Now, we're happy to announce that with JIRA 7.4, we added more fine-grained control to the Administer Projects permission, and added a few more perks for the project administrator. When granted, the Extended project administration permission will allow project administrators for the associated projects to edit the project's workflows and screens.

You can learn more about it here: https://confluence.atlassian.com/adminjira/jira-platform-releases/jira-7-4-x-platform-release-notes

As the next step, we’d like to hear your feedback about these new capabilities, and the most important features you’d like to see in the Project Level Administration moving forward.

For this purpose, we've created a new suggestion focused entirely on collecting feedback and ideas for further improvements: https://jira.atlassian.com/browse/JRASERVER-65574. We’ll use it to keep engaging with you on this topic, so please drop all your thoughts there.

To avoid having multiple suggestions about the same topic, we’re closing this one as fixed. It doesn’t mean that no further work will be done in this area, quite the opposite actually. This will help us streamline your feedback and identify some missing parts that we still need to incorporate into JIRA.

Thanks,
Jakub Lazinski
Product Manager, JIRA Server

Greg, I can't agree more. Everyone has its own definition what is safe to be delegated and what not. There are over 200 actions in the administration section. Imagine that you have to configure who has which right and understanding each of the permissions implications.
I would suggest a different approach with which you can accomplish and delegate any System admin actions and still maintain 100% control of the production server. It is described here: 100% Flexibility and 100% Control
 

I've been seeing all the various recommendations people have given about the level of control project admins should or shouldn't have, and none of them until now have really struck the right balance between their specific business needs and the general business needs.

Martin's suggestion on the other hand I feel strikes the right balance, and is the starting point that Atlassian should work from. Implement Martin's suggestion, and then go on to allow further administration rights to be enabled/disabled as the global JIRA admin(s) see fit.

Of course, it'll be another 4 years before even Martin's suggestions are implemented by Atlassian, so I'm not holding my breath.

To manage project specific values for custom fields for project admins independend from JIRA admin privilege there are multiple add-ons available

• Project Specific Select Field
• Customfield Editor Plugin
• Edit Custom Field Values
• Context Manager for JIRA

To manage versions independent from project admin and JIRA admin privilege you can use

• Version Manager for JIRA

Wouldn't it make sense to split out some individual features, such as support for project-specific values for custom fields? We also would prefer to see this feature supported out-of-the-box.

Perhaps some of these features are low-hanging fruit and could be implemented quickly. This issue is so big and the discussion has been going on so long that I doubt whether it could ever be resolved in this form...

I completely agree with Martin's comment and don't want to have to resort to plugins. Such granularity in administration should come out of the box.

lets make it clear - it doesnt make sense to allow all project leads to edit own workflows - however it might be a good idea if Atlassian could make it available as an option for those installations where consistency means less.

i very much like martin.ruppelt's comment - thumbs up ! Notice the enterprise operations level - we are a number of guys who operates like that..

but also notice, this issue is 13 years old.. Atlassian never develops stuff like this - ive spoken to them several times now, nothing happended - so if you want functionality youre better off migrating to another system... IMHO

I totally agree with what Martin says in the comment https://jira.atlassian.com/browse/JRASERVER-3156?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1536371

It is exactly what would facilitate administration in large organizations, without causing chaos.

There is a plugin that support project specific values for custom fields: https://marketplace.atlassian.com/plugins/com.easesolutions.jira.plugins.customfields.project-field-manager/server/overview.

Regarding NODs comment I would add:
I don't want what Atlassian has implemented right now: allowing a project admin to configure there own workflows. This is of no use in big organizations that like to manage there process on an enterprise level. This only leads to an unmanaged state. This is completely the wrong direction.
What I like a project admin to do is to select from given workflow, notification, security, issue type and permission schemes. And more important: have the ability to manage value lists for available *custom field*s (not allowing to create own custom fields, but having project specific pick lists).
Also JIRA group management could be handed to projects that actually need these groups. But of course it is critical that this does not mean every group can be managed. It must be specific: like: I allow this group of users to manage the following groups.

Maybe if the allocated an appropriate number of engineers to work on JIRA and through the backlog of the top 30 most-voted issues, then we might see some progress.

Seems to me like Atlassian probably have a team of 10 developers or less actually working on Jira, and everyone else is working on other products. Jira's a cash cow and they think they have a captive market, so why bother spending more resources on it?

It makes complete sense if you've seen the evolution of issue trackers and JIRA over the years.
Atlassian has added features to allow project admins to edit basic screens and workflows. It's not perfect yet but they are making great progress to changing the way the product is configured.

Totally agree with NOD. I think the permission setting in JIRA does not make sense at all. One person (global admin) can do EVERYTHING. Others (project admin) can do NOTHING.

We shouldn't have to buy yet another plugin. These are essential, elemental permissions that Jira needs to handle. We need clearly delineated permissions for those people managing users, those managing a project, and those managing the overall JIRA system.

It still works for me. Just search for version sync on the marketplace though and you should find it.

Hi @Ian Catley. I'm unable to open the link. Could you please confirm if this is the right one?

Thanks.

See https://marketplace.atlassian.com/plugins/net.collabsoft.plugins.jira.jira-version-sync/server/overview which gives another possibility for version management without needing to give project lead/deputy rights to all projects.

+1 for the need for delegated workflows per project, and ideally issue types, screens and fields as well. We have different development teams and areas (digital, CRM, BI, etc) and there are different team structures and workflows needed for each - but they have to come back to the overall JIRA admin to modify something as basic as their workflow or we have to give every project administrator full control over the entire server.  I think a JIRA admin could understand how shared workflows work, and make sure a workflow is only assigned to the projects related to a team or admin, and then delegate permissions for the workflow to the appropriate project admins or something along those lines.  Today it makes it difficult to scale across an enterprise, and as a JIRA admin I might have to start saying no to new projects on our server or look at alternatives that will support the whole business easily, as I don't have time to look after everyone's requests.

I will echo our need for this in an enterprise environment.

To reduce administration effort and allow service desk project admins care themself about their project this feature is highly required for us!

I think the new feature is quite useful and powerful but a JIRA admin should be able to close it down by project. What I really miss is that project administrators cannot configure any resolutions or force users to provide a resolution in a workflow. Even with the simplified workflow there's a checkbox "Set resolution". With this new feature, you'll end up having possible broken workflows where issues are closed but still Unresolved meaning many reports like Created vs Resolved, Unresolved by Priority etc no longer work properly.

I agree with the above:

• separate user admins
• separate project admins

However, there are some project admins that should also have limited admins – they can configure fields, change schemes but not modify workflows or statuses. Have a super project admin role, and a normal project admin (that you can assign a group to, not just one user) for basic stuff.

I saw yesterday on another company JIRA server (new JIRA version than we have) that the project admin couldn't change to a new permission, notification, or field config scheme; the project had been created with the default schemes.

Hi jennifer.zou45322308,

We hear you, and we totally agree. JIRA issue types, workflows, screens, and fields are really tricky because they are the foundation for so many other parts of JIRA, but our teams are working hard to improve project configuration in JIRA Cloud (and JIRA Server, as you can see from the most recent update) as fast as possible.

We have a high standard – we want to make it easy for folks like you to get started fast and set up projects for your team independently, but also make sure that we support the needs of people administering JIRA at scale with thousands of projects and need standardization. It's going to take some time, but this is one of our top priorities and we are hard at work on it.

Dave Meyer
Senior Product Manager, JIRA

Hi JIRA Team,

This is Jennifer from Renesas Electronics (using JIRA Cloud). I have the same problem! As a project administrator, I want to be able to manage fields, screens, schemes and configurations for my project. However, I know this can be only done by JIRA administrator. The fact is that, my organization does not allow me to be a JIRA administrator becuase they do not want me to have power on other projects. And they are right, I shouldn't have power on other projects, because I do not belongs to them. 

It does not make sense that I do not work for some projects but I have power to change their things....

This was a huge issue for our organization, because if I want to change something in my project, I need to submit a request to the IT group, and they will do it for me. This is a very long process, which may even takes a few weeks!

My suggestion is: Project Administrator should be able to edit fields, screens, add-on's for their own projects but not other projects. 

Thank you very much for considering my suggestion.

Looking forward to hearing back from you.

Jennifer.

Dear JIRA team,

As I imagined it is difficult to give us a delivery date now, please could you just let us if Atlassian plans to deliver a separation of user management from other existing project admin permissions within v. 7.3 or within a later version?

In the case of several IT teams in my company, there is a strong need for allowing either service leads or developers to manage versions themselves. New versions are being constantly needed (weekly and sometimes daily builds with new minor versions being created) and giving developers project lead deputy access for this is clearly not an option.as a consequence, I am constantly being asked to create version numbers.

Of course, we could install Holger's plugin but in or company, we have a policy of not using plugins which are only supported by a single individual. So we hope Atlassian will propose a solution to this issue.

Best regards,

Séverine

Hi jscherks1518557391,

I can't promise any exact dates but rest assured that we are aware of pain that lack of permission management regarding project admin capabilities can cause and thus permission management for project admin is high priority for us.

Regards

Tomasz Kanafa

JIRA Team

Hi tkanafa,

just to understand the term "future". How long it will take to address it? 5,10 or 15 years?

In the meantime, is there a way how to disable it? Something similar to this: https://confluence.atlassian.com/jirakb/jira-excel-export-of-issues-no-longer-opens-correctly-838403242.html (by editing jira-config.properties file) ?

Thanks

Jan

Thank you for all your comments.
I want to assure you that we are observing this issue and we will try to adress some problems described here.
We are aware of the problems with edit workflow permissions for some of our customers and we will probably adress it in the future.

Regards

Tomasz Kanafa

JIRA Team

@lists, please note that my last few sentences above were meant for he Atlassian team, not yours.

My guess is that many installations Atlassian has reviewed are simply newer than ours.

We have been Atlassian customers since 2006, and during this time, the company has changed hands as well as made acquisitions, and several JIRA admins have come and gone. Throughout our history, business teams have always been allowed to use JIRA, and their needs have dictated the addition of many custom statuses.

Meanwhile back at the ranch, we also purchased Portfolio to improve reporting capability, but it did not cover everything for us, so we created a custom solution which pulls data from it (and I know we are not alone in writing such solutions for ourselves).

Thus, we do not (and really can't make) a single unified workflow for all projects, and yet we also cannot have project admins adding random business statuses to their Dev workflows.

With the oldest business projects, I think the pain of migrating them to new schemes, which use entirely different statuses, issue types, etc, would be far more painful than simply using ScriptRunner to copy the various projects and swapping out the perm scheme.

And may I just say, the "Copy project" built-in script is a thing of beauty, which has once again improved my quality of life by quickly saving me from the base product

@adaly - I'm well aware of the problems with outliers, that's why I've voted to be able to turn it off.  It is just that there's not a vast number of them as far as Atlassian have seen.

No, you're right, it can't be disabled.

This is insane. Thanks for post this, I continue to live on 7.2.5, because I do not want to spend my life on the fact that users stumble and this don't fly - I have to figure it out.

Thanks Ignacio, I added my vote for JSW-15452.

Meanwhile, I have started adding the dummy projects to prevent people from editing.

I'll need 17 of these.

@lists, you may be interested to know why there are so many "outliers:"

In addition to the "real" one-off workflows for a few specialized teams, we use ScriptRunner, which we purchased from you

When a Dev team needs a specific post function, we simply copy the "master" workflow to a project-specific name, and make the adjustments. These all have the same statuses and transitions, but may send email to a different team, or require a different group membership to execute a transition, etc.

Thus, in 7.2, we can easily allow for some minor per-project customization without having to involve the reporting team or risking any random changes.

In 7.3, the only way to do this is to create a pile of fake projects. Ugh.

This will also mean that any new team requesting a specific post function will be unwittingly requesting yet another fake project.

It is ridiculous, and goes against the most basic concepts of system security, that this sort of kluge is the only way to protect ourselves from breaking changes.

JSW-15276 is a feature request to provide an option to disallow the creation of new statuses.

However, the ability to disable the permission to change the statuses of an already existing workflow seems to be also convenient, as many filters, gadgets, dashboards and reports can be broken.

I've just created JSW-15452 with this feature request. Please, vote & watch!

This functionality was added to support the Jira-Cloud version. Like much of the new JIRA base functionality, the Cloud and their other products drive their featureset now. Its all about Atlassian sales. The original loyal JIRA user base on the Server version is rarely considered otherwise Atlassian would've included a Disable capacity on this new feature. If Atlassian had bothered to consult even a single 100 or 500 Server installation, this oversight would've quickly identified. Seems Atlassian missed this American proverb-- Don't forget who brought you to the dance.

No, you're right, it can't be disabled.  And it absolutely should be an option for a JIRA admin to say "no" to it.  (Edit - I think being able to disable it has already been raised as an improvement with Atlassian)

But as soon as a workflow is used in another project, it can't be edited at this level.  That pretty much solves that problem in enterprise systems, as they're going to share workflows.  Only the "outliers not using shared workflows" can edit.

It sounds like April is (rightfully) raising an issue if they did not allow full admins to TURN OFF this new ability for project admins. 

New functionality is great, but turning it on unilaterally with no ability for admins to shut it off is not cool. (I haven't checked to see if that is the case.)  Just confirmed - I don't see anything permission flags that appear to allow you to turn this off. 

April, I do understand your pain, but it feels muddled.  For example:

>You have a perfectly good mechanism for this already: permission schemes.

>Why can't "Manage Workflows" be a configurable scheme permission, just like "Manage Sprints?"

 Because workflows are shared and permission schemes affect projects.  Let's say I have a "feed the cat" workflow.  I've got three cats, represented by projects Alice, Bob and Chuck.  If I gave my admin for Bob the right to edit the workflow, he could stomp on the workflow for Alice and Chuck.

The change in 7.3 to allow project admins to change bits of their workflows, if it's not shared, is a (small) step forward for the enterprise, and, everyone else.  You can delegate control to your users, while retaining control where you need it.

I agree with you in that we would like to be able to delegate specific permissions (As an admin, I don't want to do user management stuff, can I just hand over group maintenance to HR and project maintenance to the projects?).  But I can't make out what you're actually looking for here?  More rights for people to change their projects?  Or less, as you mention you have to do loads of cleaning up?

This is the worst case scenario.

Unfortunately, given the introduction of these new powers with utterly no thought to controls or reporting requirements, it will be a very long time before 7.3 gets deployed in our environment.

If the permissioning situation is not improved, then I have to either create dummy projects for each of the business teams who have one-off workflows, else I get to spend hours removing all project and board rights from everyone in the affected projects, and then perform every single add or change for all sprints, projects, versions, components, etc., by myself, just to protect our executives from unexpected (or worse, undetected) reporting failures.

In short, this is a giant leap BACKWARDS for the enterprise environment.

Sometimes, I honestly wonder if you just hate us larger customers for some reason... We need a way to delegate permissions, not mass-grant them to all by default.

Delegation is a widely used security concept, so I think you should already be familiar with the idea. In brief, it means granting an administrator the right to delegate specific duties to others, in a controlled way, as well as to remove those permissions as needed.

You have a perfectly good mechanism for this already: permission schemes.

Why can't "Manage Workflows" be a configurable scheme permission, just like "Manage Sprints?"

Please, for the love of God, have a little mercy on us!

7.3 was released on Jan 3 I believe. It looks like they added a bare minimum of project admin capability and turned on by default. Proj Admins can now do minimal workflow editing - no status adding, no editing of shared workflows, and they cannot select screens. They also cannot touch validators/post functions/etc. Pretty much just 'add existing statuses to the flow' and 'edit transitions'. 

It would be good if a full JIRA admin could choose what config permissions a project admin could have delegated to them. I agree with April that it would be a nightmare if most (if not all) project admins could modify or add statuses.

Haters gonna hate...

No to be overly negative but has it seriously taken 12 years to get this feature implemented?

Happy to hear, When can we expect JIRA 7.3 release? Will it takes long time or short?

I'm praying that this will be implemented as a perm or that there will be some way to save myself from random changes, besides making hidden dummy projects so that the one-off workflows will be shared and un-editable.

For anyone who uses Scriptrunner or has custom code, there simply can not ever be random changes to transition or status names, and God forbid they start deleting post functions.

And for anyone who ever had any sort of reporting, statuses need to remain consistent.

Thankfully, the new Manage Sprints permission has helped us greatly reduce the number of project admins.Great job on that!

Atlassian, it would be amazing if component management could also be delegated, as this would allow us to finally remove the remaining unwanted project admins.

@srenou yes this is the idea. This is also a way to avoid you to modify projects where you are not admin and where the workflow is shared with.

You indicate that project admin would be able to change only if the workflow is not shared with other projects.

If I am project admin of 3 projects, and I want to maintain them with the same workflow and I want to be able to change that workflow, it seems that it would not be possible?

My only way would be to create 3 independant workflows that I would need to change each individually?

thanks for any feedback.

Yes I agree with icatley. Even if "local statuses" is a good thing to have(if it is configurable), I think the main topic of this feature request is not that.

To me it is the ability to delegate some rights.

I think the 2 most important delegation powers are : 

• ability to create a version within a project without the "administer project" right (a separate right would be fine)
• ability to name a "group administrator" who can add and remove persons from his/her group. That would ease the job of project admin when there is a linked Confluence space.

@Robert Mota: You might want to vote for this feature request:
https://jira.atlassian.com/browse/JSW-15276

I agree with Karen Hayden. In addition, in my opinion each section of project administration should have the option to allow or not allow. I don't want project administrators changing the permissions or notification schemes either, when they are shared. We have hundreds of projects that use the Default schemes, for maintainability and users not realizing it's going to affect hundreds of projects change things!!!