eerg.. I was afraid of that.. And it's goign to cause us some sarbanes oxley issues if they don't fix it. basically, we can't have business users with admin if our code is in the same ondemand.
Given I was able to find requests in the Jira Jira for this from ~2006, it's a shame they haven't sorted it by now.
All we'd need is a permission allowing workflow editing for non system/default workflows. Either on a one-off situation, or for workflows tagged/tied to a project.
Ideally, a project admin could clone/copy the default system wide workflow, and edit it.. No harm outside that project.. (possible crazy workflows sure, but the editor is pretty straightforward these days)
I'm not sure it's going to be fixed any time soon. There's a good reason to prevent project admins having access to the full set of workflow options (I'd say one quarter of my career with Jira admin has been made up of cleaning up the mess made by "oh just give everyone admin rights").
In fact, thisu control is better for SOX compliance - it means you've got a tiny handful of responsible people that you need to trust anyway - your admins. You can point at it and say "it's all locked down, if any data goes missing, it was an admin, there's no way a PM could hide stuff"
There is some movement though - the Greenhopper simplified workflow allows a project admin to set up a skeletal workflow without getting any other system rights.
Don't know if I'd call the greenhopper simplified workflow a workflow at all (it's everything to everything star pattern at best).. but yes, that might quell the "need" by folks higher than I in the food chain who "have to" to edit their own workflows.
And part of the original desire for workflow editing would help with SOX as they could edit the workflow without having delete perms on the issues themselves.. We already had to remove the delete permission from admin (they don't know how to find it to turn it back on thankfully).
Anyways, thanks, I'll try the simplified route tomorrow.
Same here - it's definitely aimed at projects that don't really have much in the way of a fixed process to go through. Good for agile development processes, and good for simple to-do type stuff, but a lot of people use workflows to mirror real life processes. For example, getting systems from development to production, via sets of plans and authorisations, which means things MUST be done in a limited order.
yea.. for my project I tried to add a "Test" step between open and resolved.. but I want the developer to "resolve" it from open into test.. and then have the originator test pass/failed it into resolved (or reopened).. but in that first resolve step, the resolution gets set and the jira is "done" strikethrough throwing off other jira widgets.. turned it off for now, but that was the goal..
This is really a limiting function. We are using an enterprise JIRA setup which has many JIRA projects from many different organizations. The administrators are very removed from the users - they (naturally) have a very different role than the Project Admins. The Project Admins (or some other permission) should be able to manage the workflows for their own Projects. The simplified workflows are pretty limiting. I'm kind of shocked this functionality is not there. It sounds like to define a workflow I need to go through a third-party who doesn't understand my "business needs" and shouldn't really have to care about them, frankly. They become a single chokepoint for organizations that are rapidly refining and/or changing workflows as project needs changes.
I do understand that argument, it makes sense. However, in the real world, your project admins are not generally not skilled enough to be trusted with workflow construction (design, yes, but not translating that design into the signficantly complicated thing that is a real workflow), and that's really not what you want them doing - you want them running your projects, not spending days tweaking workflows and maintaining a system that is supposed to be there to support them and let them get on with their actual job. All but one of the jobs I've taken in the last 12 years has started with "Could you clean up the mess made by inexperienced admins screwing up the config?" Often fields, but it's mostly workflows that have been broken. The typical pattern of disastrous failure is "we made our project admins into system admins because they wanted to change the workflow". Workflows are complex. The vast majority of project admins do NOT understand the details. Having said all of that, try the "JIRA Agile" "simplified workflow" option. It really does simplify the workflow to the point where the project admins don't need Jira-workflow skills.
I totally understand what you are saying, but having JIRA Admin = Workflow Constructor and no other option is too limiting, IMO, because it assumes too narrow and specific an association of responsibility. I'd rather have a rope long enough to hang myself with rather than one a little too short to climb out of the hole someone pushed me into!
Have you tried editing a workflow? More importantly, have you ever supported a JIRA where a non-JIRA admin has been messing with a workflow. It would be great to be able to delegate workflow maintenance, as I said before. But because of their complexity in their current implementation, you simply can't afford to do it (irrespective of the other admin rights). You *will* end up with a lot of badly hung corpses.
It is fixed. In real life, project leads editing workflows is an unmitigated disaster, so it's not going to happen like this.
In JIRA Software, you have the option of "simplified workflow", which gives them the ability to set their own status and flow, but none of the clever stuff that so often goes hideously wrong.
On the plan for later, I understand that the aim would be for project admins to choose workflows from a list that admins define.
Well, in 7.3 it is now possible, to a limited extent.
For what it's worth, we've already picked up several pieces of work for "cleaning up the mess made by project admins when let loose on the workflow", and the ability to turn it off was added to 7.4 as a matter of urgency, as it created a massive spike in support calls to Atlassian from what I heard.
But if you're happy with the risks, upgrade and take a look at your projects. If a project is using a workflow that is not shared with any other projects, then you will find project administrators can edit it. They can't get at all of it, but they can design their own now.
It is now 2019 and the situation still seems the same. In the above discussion there is a limitation in your approach to reality.
You discussed the administrator and the project-lead. The role missing is the workflow specialist. Not every JIRA administrator understands workflow well enough. Some project leads understand it better than others.
I would very much support the adding of a role the allows some people to control workflows. I could then even organise a course to educate them in just that. Right now this is not possible. Its all or nothing. So I would really allow for the in between role. The workflow-specialist.
You can't do it. Only administrators can edit workflows.
Simplified workflows are different - they follow the columns set up in the board for the project. That means anyone who can configure the board can configure the workflow. But only in a very simple way.
They can change status (in a simplified workflow). If they add a column, they can create a new status for it.
Transitions are simplified to "you can always move from one status to any other". Permissions and the rest are also simplified and fixed.
I may or may not be on the same line of thinking as represented here, but I just had this issue come up yesterday and, being new to the organization and JIRA, was curious about it. The Project Lead was unable to delete a test project they created, or edit/change issues. I originally thought maybe there was a way to make the Project Lead also the Project Admin, but I can see where that isn't necessarily the best option all the time. However, I finally found where I can assign the person as the admin on individual projects. So it seems, for now at least, I will just do this when a specific complain comes to me. We are also a large organization with many projects in many areas of the business.
So, can we have someone explain why exactly JIRA feels that users are so incompetent they must restrict usability to prevent them from their own inability? To the point where not even having the ability to opt-in to a setting to give them the power, no, that's still too much for our poor users, but just restricting the ability entirely.
Many enterprises have a single team who administers JIRA for the organisation, to simplify things from a cost and maintenance standpoint. This is normal, expected, and should be accounted for. Obviously, the dozens, hundreds, or even thousands of users/teams will have different needs for workflows, notification setups, etc. Not everyone is the same, and in larger organisations, the type of work can be completely different. Yet, from what I can gather from reading the responses on this issue, JIRA is of the opinion that since some users give the wrong people admin access and they mess settings up, we shouldn't have the power to give the right people access to change settings for only their own domains, because what if they're bad at it??
In my opinion, it is not JIRA's job to tell me my project manager is incompetent. That's their boss' job, and they'll deal with it when that occurs. JIRA should be providing us with good software that enables us to manage our team and projects better. However, it seems that they'd rather try and demean the capabilities of their users, and lock out critical features to that end. PLEASE reconsider this approach, and even if it's an opt-in setting that's disabled by default, allow admins to make the conscious choice to let certain project admins control their project when necessary, because as you know from the amount of posts about this both here and on forums, stack overflow, etc. it is something many users clearly need.
Experience and evidence.
More than half of my career with Jira has been "fixing the mess made by people". Not so much their own mess, but the mess they make when they break other people's stuff. To the point where we removed project admin rights globally as a result of "not wanting to have to spend even more time satisfying auditors and sacking people". I've seen weeks or months of work that could have been lost (sacrificed for "forget today's work folks, someone means we need to go back to last night's backup"). We have to assume people who can get it wrong, will, and badly.
Atlassian have some work (which is still continuing) on allowing people to have more local control of their own stuff, but it takes a lot of re-engineering.
Dear Nic, as an educated person you can’t seriously agree with your own answer. When an employee understands the workflow functionality, and you give him/her the permission to manage hisbown workflowscheme and workflows, there is no difference from having one administrator with the same knowledge perform the same actions.
In the current situation there is only one option and that is to provide Jira Administrator rights to the one that want’s to manage his own scheme and workflows. There is more risk involved in that than in giving permissions for managing workflows alone.
In my opinion Atlassian should provide a better alternative.
I think you've missed the point here. If an employee understands it, there is no problem - they won't make a mess. The point is that you should not let people who do not know what they are doing have the access to inflict their ignorance on others.
The "better alternative" is "don't let the incompetant break anything outside their own stuff". Which is what we have at a higher level and has been cascading down over the last couple of years.
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events