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.
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"
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.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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