Loophole found in Simplified workflow, allows workflow state creations for Project Admins

venkateshprasad July 13, 2021

Hi,

I was recently browsing through an article which talks about the difference between Simplified Workflow and Jira Workflow. Below is the article link
https://confluence.atlassian.com/jirasoftwareserver/using-the-simplified-workflow-938845286.html

To test the Simplified workflow, I then created a Scrum Software Development project (Did not use the Create with Shared Configuration while creating project) which also created a board and workflow by default.

Loophole :
The project creation will also create Simplified Workflow and board. If you navigate to the project and then go to the 'Board' and select 'Configure' and navigate to 'Columns' section, on to the right side of the screen, you will see 'Add status' button.
Please note that a user with a 'project administrator' role will be able to add and existing workflow OR 'Create a new workflow' from this screen.
This workflow state created from this screen is a Global item, meaning any workflow (be it a Simplified Workflow or a Jira workflow) can use this state in their workflows.

It would be haphazard if such privileges are given to the Project Admin levels who may start creating workflow states as per their project requirements but that workflow state would be added globally for everyone to use.
As on today, if a company uses both Software Simplified Workflow and a Jira Workflow (maintained by Jira admins), then such companies will have troubles controlling the Workflow State creations.

Just a thought from my side on how this could be resolved. The product development team could think of making a few architectural changes in the way the application holds this data in their database. I mean, they can have separate Pools for Simplified workflows states and Jira workflow states instead of storing/mixing up everything in the same place in DB.
Also, within the Simplified workflow states Pool, there can be project specific Pools which will hold the project specific workflow states.
By this, the workflow states can be specific to only those projects which create them, rather than sharing it globally.

Please share your thoughts and opinions.

3 answers

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 13, 2021

Ok, this is not a "loophole", it is intended to work this way.

Project admins are supposed to be able to create new status for their simplified workflows, it's one of the main reasons for implementing simplified workflows.

As for the haphazard or global effects, there's something missing here - they can only add (or remove) status from simplified workflows they control.  Changing a simplified workflow only affects that workflow, it does not affect others.  And a simplified workflow is limited to the projects that the admin has access to.  You can't change other workflows, only the simplified ones you own.

There is one problem here you have correctly identified - yes, the list of status is global, so in theory if a simplified workflow uses a status that non-simplified workflows use, they could rename a status.  Note that the status is just a label, it does not change any workflow using it, it is JUST the label.

The Jira admins (of which you only have 3-10, working in a single team, right?) simply don't use shared-workflow built status in the main workflows, keep a lookout for status name changes, and have a duty of education to the project admins "Yes, we will enable simplified workflow for your board across your projects, if you promise not to rename status".

Then again, the system I looked at most recently didn't allow status to be edited in simplified workflow, if the status was used by any other workflow.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 27, 2021

I'm struggling with your description of this as a "loophole".  To me, a loophole is "a way to get through something that I am normally blocked on doing because I'm not supposed to be able to do it"

Being able to create new status that have no impact on anyone else is not a loophole.  It's there by design.

The whole point of simplified workflows is that people can create their own, and that means they need to be able to create new status as part of it.

If you have a problem with this, then there is a simple answer - you need to control what your projects are doing centrally, so stop simplifying workflows.  Remove existing ones, swapping them to a fixed workflow scheme.  Problem solved.

0 votes
venkateshprasad July 27, 2021

Hi Nic Brough _Adaptavist_

Thanks for sharing your thoughts and sorry for the delayed response as I was on vacation.

The question still remains and I still believe this is a loophole in the product.

Explanation :
For any user to create new Statuses in Jira, they have to go through the Admin Portal. Meaning, they have to go to
Administration --> Issues --> Under Statuses section, click 'Add Status'
or
Administration --> Issues --> Under Workflows, from either an existing or a new workflow, you will be able to create new Statuses.

In both the above options, Jira application has been designed in such a way that the Status creations should happen only by the user having Jira Admin rights.

But, with the Simplified project, a user WITHOUT Jira Admin rights, having just project admin rights, will be able to create Statuses which will be Global.

As I mentioned in my earlier comment, this will be a problem if a company uses both Software Simplified Workflow and a Jira Workflow (maintained by Jira admins), then such companies will have troubles controlling the Statuses creations.

Please also note that a Status created by one project's admin is accessible globally by all other projects in that jira instance. Meaning, other project admins from other projects can start using those statuses.
If there is no distinctions between which Statuses are Global items and which Statuses are project specific items, this may mess up the whole setup.

Big companies like ours have thousand projects and if each project starts creating their own Statuses, we will have 1000 statuses to deal with, Not at all the right way.

I strongly feel there has to be a way these project specific workflow statuses are managed within Jira Application.

Donna Elwood January 6, 2023

I agree with @venkateshprasad  We have thousands of statuses, projects and users spread across the globe.  We centralized the admin function and are attempting to clean up and remove statuses while users are creating new ones.  As admins, we have to monitor the system to see if new statuses were created outside of our group. 

In addition, when the project and workflow is created, it is not created as a simplified workflow. The board administrator can select  the "Simplify workflow" button and change it.  I realize a global simplified workflow can be created and associated to new projects when they are setup to avoid this issue.  However should one of those projects require a workflow change that brings us right back to the original problem.  A project with a simplified workflow.   

There should at least be a way for the system admin to turn this feature off.  

Suggest an answer

Log in or Sign up to answer