-
Suggestion
-
Resolution: Fixed
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
With 7.3.0 you've released the project level admin to give project admins the ability to change workflows (albeit under relatively tight restrictions - not shared, using existing statuses etc), however given that users require project admin for various tasks (version/component/etc management), we need to give a variety of staff project admin rights. Given our workflows need to go through internal change management and audit, we cannot allow these workflows to be edited. While this could still only happen in limited projects, this is something we cannot permit to happen.
I get this is a huge benefit to many teams, but going to cause compliance issues (or even just headaches with people changing without handling change management ) with numerous as well so there should ideally be an option to disable this on a system wide level.
- is incorporated by
-
- Closed
- relates to
-
- Closed
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-63684] Ability to disable Project level administration
Kamlesh Rao
added a comment - Please fix this by getting us options to disable edits either globally or best case per project.
Kamlesh Rao
added a comment - Please fix this by getting us options to disable edits either globally or best case per project. We constantly have project admins creating nightmarish workflows that don't manage resolution state when opening or closing. Seems like this is a serious consideration that should have been handled before allowing admins to go hog wild with this.
So when JIRA software can add Option to disable this feature? It has been in progress for 3 months.
Great News 
One workaround to disable this is to create a dummy project and make sure an issue type in that project uses the workflow. Doesn't scale well with number of workflows and issue types though. We really need to be able to disable this feature for enterprise customers!
This is a most welcome addition to many customers but far from all! As discussed in previous comments there are lots of companies relying on different levels of process control. It needs to be recognized when adding a feature like this.
I am an Atlassian Solution Partner and I am working with lots of different customers for which many I am responsible for the workflow configurations. This is regulated in different SLAs which I, as a contractor, am measured against. With not being able to disable the Edit Workflow feature for Project Admins I need to do some drastic changes in all configurations. E.g. making sure all workflows are shared. This would require a major change in the already large JIRA instance. I ran the script provided and the instance has 150 project workflows that are affected. Making these workflows shared is a complete waste of time and resources and it also adds tons of complexity to an already complex instance (400k issues, 15k issues/month)
Another approach would be to re-negotiate the SLAs with all customers and exclude the responsibility for the Workflows. I don't see this as a viable solution though.
The obvious solution to this would be to do something similar the JIRA dev team did for the Sprint Management a while back. Back in the days you needed Project Admin perms to manage sprints. This was a pain since you had to add people to the Admin role granting them lots of permissions they didn't need (or should have) to be able to manage their sprints. This introduced the new permission level: Manage Sprints controlling this
Shouldn't it be possible to add a new Permission called: Manage Workflows? This would make it possible to either disable it completely from the JIRA Admin side which controls the Permission Schemes or enable it for certain users in the Project view.
This is actually quite well described in this related feature request: JSW-15452
Not quite the reaction I was hoping for