Checkboxes on Create Issue Mask are controlling a sequential flow (define sequence)

[BA-RD Systems]

I got the task to create a JIRA workflow,
which has checkboxes on the Create-Issue-Screen.

The Checkboxes should define if a workflow step is involved or it has to be overstepped.

Can you please tell me how to ask for a marked checkbox and how to overstep?

See which_stations.jpg how the Creation-Mask should looks like
See michaels_draft.jpg for the workflow

Original Requirements (see also Excel upload):
¦The numbered rows of the attached file are irrelevant for the workflow, are only examples.
¦Each green and pink column represents a workflow step.
¦Selectability of a step is indicated in the green row.
¦Each step is executed in serial order at first, but possible parallelization needs to be evaluated.
¦A feedback of the Design Control workflow is possible, but only to the Design Planning step.
¦The "Design Planner" assignee will be the owner (or Moderator) of the topic.
¦Each Design Control step will have a default assignee, in the person of the leader of that group in the given project which can then be delegated.
¦The workflow can be used for both feature inplementations as well as bugfixing.
¦The workflow being serial, each future responsible should get a notification of any preceeding transition, to enable team/parallel work.

[Norman Abramovitz]

I have seen specifications like this before and what they are doing is a dynamic workflow which is very painful to implement in Jira when there a great deal of states.

What you need to do is do is get more information about the high level tasks, so you can create multiple workflows to cut down the number of states to a managable number per workflow. I am assuming all your states would never be used for a particular task. You will need to create different issue types corresponding to the different workflows. You might have hundreds of workflows/issue types, but each individual workflow is managable.

You will then need a plugin to manage the relationships between the various issues unless a two tier issue structure would work for you. This will allow to you to have parallel issues active and be able to serialize issues.

The hard part of the above approach is getting the person to realize that dynamic workflows are dangerous since steps can be missed(ie human error) and getting the people to discuss what combinations actually makes sense together for the actual tasks being performed.

Another idea (but I do know if it will work or not)

If you have a common(static) structure to the these states/workflows like what is being shown in your picture, you might be able to used a scripting language during a transition and be able to change the issue type on the fly or communicate to an external process that would change your issue type using the rest api. In this case each state would have its own issue type. Again parallel issues would need a plugin to manage the relationships between the variious issues since the relationships needs to be shown within Jira. There is some new framework coming out or is out for the external process approach.

[Norman Abramovitz]

BTW. Good Luck.

[Nic Brough -Adaptavist-]

There is no such thing as "overstep". You need to define a transition for each possible change of status, and then use "conditions" to hide transitions that should not be allowed.

An example condition here might be "do not allow Risk -> Hardware if the field v-model stations has the value risk-management"

[BA-RD Systems]

Thank you very much for your answer. The problem is with 21 Selectable States and from each state to each state one transition will lead to 210 Transitions. But it looks like we will have 28 this would be 378 Transitions for the workflow to define. Hmm is this so good :/

[Nic Brough -Adaptavist-]

You could use global transitions - define one that goes from <any state> to <specific state>. The starting point for one of these transisitions is "any status". That would cut it down to 21 transitions!