Allow project admins to edit shared workflows

[Steffen Becker]

I know project admins can only edit their workflow if this workflow is not shared with other projects.

But I have the following scenario:

One user is project admin in three projects and he'd like to use (and edit) the same workflow for all three projects.

So my suggestion is:

Allow project admins to edit shared workflows if they are admins in all projects which use this workflow.

[Mirek]

I do not think that this is the vision that Atlassian is implementing. From one side they introduce ability to edit workflows but on the other as you mention it must have independent configuration (not shared). That is also introduced in a new "next-gen" project type in Jira Cloud.. (every project have own configuration)

I personally do not think that this is a good approach. Everyone knows that the best practice on Jira Server is to reuse configuration (if possible). That is also noticed in Atlassian University trainings. Adding features that push people to make configuration unique per project add more not needed objects in the database and overall over time means decreases performance.

As for your request I do not think it is good in many situations. Imagine that you have one admin that is only the admin of one single project and cannot be in 2 more. On the other side you have admin that can administer 3 projects. How would feel the admin of the single project if he see that someone else can edit his workflow but he cannot. He would like to have also that permission even that it requires making the configuration unique and loosing the flexibility of sharing.

Another thing is that your scenario is only for 3 projects. What would need to happen if you share the workflow with 10, 20.. or more projects? You would like to make admin only to give someone permission to edit workflow and do some small change that would break the company standards

For me this "Extended project administration" could be completely removed. It introduce more problems for experienced and certified admins than "good things".. In my Jira instance I have projects that have configuration shared with 400+ projects and imagine if everyone would like to edit their workflow. I would need to create 400+ unique configurations just to satisfy their needs. At the end I (as Jira admin) still need to help them because they cannot do this/that or cannot understand the workflow design principles.

So faster, cheaper and safer than giving them that ability is to ask Jira admins directly. This design was working for almost 15 years in Jira and overall not many people complained about that..

[Steffen Becker]

Thank you very much for this detailled feedback!

Especially the 2nd and 3rd paragraph contain very good arguments.

But regarding the "ALL projects should use the same scheme", I handle it different than you:

In the past (and still in the present in many use cases) we use(d) "Ivanti Service Desk": Everybody I know hates this tool because of the bad UI & inflexibility. That's why we switched to Jira. I administrate about 200 projects. Most of them use our standard, shared company schemes. But some projects have different needs and there are very experienced Jira users who think they are limitated by our default schemes. If we would force them to use our default schemes, it would look like "another inflexible Ivanti" to them.

But this only happens for about 10% of the projects, so that's why we decided to create custom schemes on demand.