Workflow design question

[Jesse Wu]

* A device can go through a full certification (which has a set of steps). Else a device can be similar enough to another device to be certified-by-proxy and pass automatically if another device passes. We are considering either (1) making a single workflow that captures both cases, or (2) creating a different workflow that you can switch the issue to. The advantage of (2) is that we don’t complicate the first workflow. What are the disadvantages and limitations of (2-creating separate workflow) are. Can you help elaborate on when it would make sense to consider 2 different workflows that an issue can travel through vs. one? Can you search across workflows? (we wouldn’t want the issues to be segmented)

* There is the notion of “sub issues” in JIRA, which I understand to mean that you have to resolve those first to resolve the parent. I’m interested in creating almost an inverse of that. I would like multiple issues to depend on one getting resolved. When the one gets resolved, the dependent ones get unblocked or get resolved. Can I do that with JIRA sub issues?

[Dieter]

The consequence of having different workflows is that you have to _move_ your issue in order to stick it to the other workflow. This is not very intuitive for users. Also moving your issue is possible in any state it is in as long as the user has the permission to move. This probably something you do not want since it let's a user stick an issue to the other workflow while it it in the middle of the first workflow. Having one workflow only would allow you create a more complex logic based on workflow conditions to control the switch to the other workflow. Please also note that having different workflows might induce redundancy in maintaining your workflows in future if you discover that both workflows have some common steps or actions. These actions could be easily handled by global actions if everything is in one workflow. Regarding usage of subtasks: there is no logic inside standard Jira that checks if subtasks are resolved before the parent task is resolved. But since this is good practice there are plugins around that suport this. The same can be done for the usage pattern you describe. A plugin can automatically resolve all the subtasks (maybe just the one of a specific type) once the parent task is resolved. i usually do this in a transition which is called "resolve issue+subtasks ". this transition sets the resoution of the parent task using the Jira Suites Plugin and executes the Close action for each sub task from a Groovy post function script. there maybe other solutions around and i am sure you get more than one answer asking that explicitely again. So the answer to your second questions is yes, you can do that but not with additional plugins and/or programming.

[Dieter]

My previous answer did not cover the case that the workflow is selected at the time when the issue is created. To me this seems difficult since it means the one who creates the issue can already decide which workflow has to be used. (either by creating the issue in the right project or by choosing the right issue type). You should consider this aspect very carefully . As previously said moving the issue later has severe disadvantages