nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow: Different Start States For Different Issue Types In One Workflow?

Gregory Suddert

I am dreaming, of a magical plugin. This plugin, or maybe just a magical coffee cup, would let me have a big scary workflow, and four issue types, and those issue types would have different starting points in the workflow, and from that point, they would transition normally.

Is there a way to do this without any of the programmatic stuff I've read about online? The reason I am suspicious of something that has to manually transition an issue through a big workflow is that its like having two workflows--one in the tool (JIRA) and in the plugin. If we have 4 issue types, then "old skool" (no plugin) we'd just have four identical workflows.

I'm asking this just as a way to reduce potential errors in maintaining 4 copies of a big workflow.

Thanks in advance!

Accepted answers

Michael Postman

As I understand Gregory tries the following:

He has two issue types (e.g. "Bug" and "FeatureRequest").
Then there is a workflow with the following steps:

Effort-Estimation
Budgeting
Development
Testing
GoLive

When a "FeatureRequest" comes in, ist begins at step one and all the budgeting takes place.
When a "bug" shows up, there is no "Effort-Estimation" nor "Budgeting" as this is not necessary, a bug needs to be fixed, quick.

So the classic solution is to build a new workflow which only consists of steps 3. to 5.. Because all the development, testing and GoLive is the same for "Bug"s and "FeatureRequest"s.
That's what we did in our workflow.

The downside is, that if you need to change something in the "Testing"-part of the workflow you need to do the change twice, and you have to make sure you don't forget anything.

This sounds interesting for us too...

One possible way I could imagine is to add a step "0. Open". The "create" transition which is automatically there points to this new "Open" step. This step has two transitions. One pointing to "1." and another pointing to "3.".

We just need a "Condition" on the Transitions to only show the relevant one based on the Issue-type.

However such a condition does not exist in Jira itself nor in the Jira-Toolkit plugin.

@Gregory: Did I get it right?

@All: Any further suggestions?

All comments

Adam Saint-Prix

Gregory,

When you say you would like different starting points in the workflow per issue type, what do you mean exactly? Can you give an example using two issue types you have in mind? On the surface, what you're asking for sounds possible, but I'm wondering if I'm missing something.

You can have a workflow scheme that contains multiple workflows per issue type and these could all in theory have different starting points (depending on how you define start point) and then converge (or not) if you so choose.

If you haven't seen them already, the docs on Configuring Workflow are probably a good starting point, but if you can provide more specific examples of what you'd like to do there are a lot of people in here that are very good at workflows who can probably help. At first glance though, it doesn't sound to me like you need a plugin for what you're looking to do.

Michael Postman

As I understand Gregory tries the following:

He has two issue types (e.g. "Bug" and "FeatureRequest").
Then there is a workflow with the following steps:

Effort-Estimation
Budgeting
Development
Testing
GoLive

The downside is, that if you need to change something in the "Testing"-part of the workflow you need to do the change twice, and you have to make sure you don't forget anything.

This sounds interesting for us too...

We just need a "Condition" on the Transitions to only show the relevant one based on the Issue-type.

However such a condition does not exist in Jira itself nor in the Jira-Toolkit plugin.

@Gregory: Did I get it right?

@All: Any further suggestions?

Gregory Suddert

Thanks for your answer/question. The workflow docs are an alien text we're pouring over, full of mystery and promise. Right now, we're babes in the 'flow woods. I'll expand on the answer below. Thanks again!

Gregory Suddert

This is the basic scenario. The real workflow is a big chutes-n-ladders affair regarding build, testing, deployment. The reason there's multiple Issue Types is that somethings (COTS products for instance) don't need build, but, they need a different type of testing, and still need to be scheduled for deployment etc. I like the idea of using different Issue Types because they give us the ability to say where they should start, in my dream world.

Simple example: Potroast Dinner:

Purchase Potroast
Defrost Potroast
Preheat Oven
Roast Potroast
Make Side Dishes
Serve Potroast Dinner

So, if you start at various stages, its a different dinner. If you start at:

Make complete Potroast Dinner
Make frozen Potroast Dinner
NA
Make fresh-not-frozen Potroast Dinner
Make sides-for-Potroast-leftover Dinner
Server from-the-hot-deli-section no-work Potroast Dinner

Same workflow, but, the nature of the request is different based on where you enter it.

Thanks y'all!

J Thomas4

You can do this with the Script Runner plugin using the Fast Track Transition An Issue script postfunction - see https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-Fasttracktransitionanissue.

So start your workflow at an initial status, say Open, create transitions to all the statuses you want to move each issue type to and add conditional fast track transitions at the end of the Create transition's postfunctions to move each issue type from Open to the required status.

Radu Dumitriu

If you do not like too much programming, maybe my baby will make life a little easier for you ? https://plugins.atlassian.com/plugin/details/43318

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

issue

workflow