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.
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.
Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs