Status: Gathering Interest (View Workflow)
Atlassian Update – 20 December 2017 Hi everyone, With Jira 7.4, we released the ability to disable the Extended project administration option. By default, the option is enabled which allows project administrators to edit the associated project's workflows and screens. In case you would like to delegate only specific configuration options, like workflows, we recommend using one of the Marketplace apps that provide this capability. Delegated Project Admin Pro for Jira is a good example. Additionally, we would like to hear your feedback regarding the most important features you’d like to see in 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. Thanks, Jakub Lazinski Product Manager, JIRA Server
As a JIRA Administrator, I would like to be able to disable the new capability of project admins to modify a project's workflow (introduced in JIRA Software 7.3) so that I can ensure the integrity of already existing:
- Confluence pages that get info from JIRA
as many of them can (and will) be broken when they were built with the previous workflow statuses in mind.
Therefore, this capability needs to be controllable at different levels:
- Instance (ON - OFF)
- Global permission: control group(s) of users eligible to have this capability in projects.
- Project permissions: ** new permission to be added to the permission scheme.
Note that level 2 seems to be redundant due to the existence of level 3, but it isn't really:
It should be possible to grant the new permission to a project role, and, simultaneously, not effectively granting the permission to a user that doesn't belong to the group of people set on level 2.
That's specially relevant when you don't want some project admins to be able to have this ability, but they could add themselves to the project role which grants this ability.
Also note that adding a group to the permission scheme instead wouldn't solve the problem.
So, for a user to be able to have this ability, all 3 levels should be true.