How to make the parent issue take on a status of a sub-task based on different sub-task transition.

[Dimitry Chewski]

I'm not too familiar with scripting but have been doing research where I just want to make sure this is even possible with Groovy. 

I've setup the parent issue to follow the transitions of a sub-task. The next step is when that sub-task goes to it's "Done" status, we want that parent issue to transition to the status of a different sub-task under that Parent issue. 

Is this even possible with Groovy Scripts? I'm stuck on trying to get the parent issue to take on the status of an entirely different sub-task when that initial sub-task is completed. 

Thanks in advance. 

[Earl McCutcheon · Accepted solution]

Hi Damien,

I misread your initial question and thanks for the clarification and you actually don't need Groovy script for that and you can set this transition up using JMWE Transition Parent issue post-function in conjunction with the JMWE Subtask blocking Condition:

• First add the Transition Parent issue post-function on the "Done" transition to trigger the "Done" transition on the parent when the Chid issue/Sub-task is set to done
• Next Set the Subtask blocking condition on the "Done" transition, specifying that all sub-tasks must be in the "Done" status for the parent issue to be transitioned

Regards,
Earl

[Dimitry Chewski]

Thanks again for all your assistance Earl. So I've actually been able to set that up so far. What I'm ultimately trying to do is probably best explained with an example.

I have a parent issue and two sub-tasks. Sub-task one transitions through the statuses and the parent issue follows along the same transitions except when it reaches "Done". Ideally, when sub-task one hits "Done", we want the parent issue to take on the status of sub-task two and follow along that transition until it is complete. I hope that clarifies what I'm trying to do. 

The link you provided seemed to be pushing me in that direction but requires ScriptRunner. I'd like to know how robust JMWE is with the included Groovy scripts. I've done a fair share of testing with the JMWE conditions/validators/post-functions but get stuck at trying to get that parent issue to take on the status of another sub-task at the "Done" transition of the initial sub-task. 

Damien

[David Fischer]

Hi Damien,

you can achieve the same things in ScriptRunner and JMWE using Groovy. But what neither of them will allow you to do is modify the status of an issue without transitioning it.

So, what you need to do is, on the "Done" transition of subtask one, add a Transition Parent Issue post-function but use a "calculated" transition name (or ID) using the "Groovy Script" Transition type. You'll then be able to "calculate" which transition should be triggered on the parent issue, based on its _other_ subtask, to bring it to the desired status.

However, I'm not sure I understand what you mean by "follow along that transition until it is complete".

[Dimitry Chewski]

Thanks David,

The "follow along that transition until it is complete" meaning that the parent issue will change with the transitions of that second sub-task up until it's done unless all other sub-tasks are completed. 

I'll give this a try and see what happens but just to confirm, when you say "calculated" transition ID, you mean the ID for the sub-task that the Parent issue will be transitioning to?

Damien

[David Fischer]

Actually, it's a little more complicated than that, but I'm still unsure what you're trying to achieve. How do you differentiate the "first" from the "second" subtasks? Are they of different issue types? Do they have different workflows?

[Dimitry Chewski]

I guess that's the question I'm trying to figure out to make this work. Currently, they are using the same issue types and workflows. I just can't figure out how I can get the Parent task to be able to identify the status of the "second" Subtask to transition itself after the "first" Subtask is completed. 

Thanks again for your assistance. 

[David Fischer]

Ok, I probably wasn't clear. Are these two subtasks different in nature, or is the subtask you call "first" just the first of two similar subtasks that reaches the Done status?

[IT Team]

It would be the latter. Where they are similar sub-tasks in which they share the same flow and parent issue. Hopefully this image better gives you an idea what I'm trying to do with me previous description (statuses are different though but same idea when the "first" subtask is done, the parent issues defaults to the status of the "second" subtask. 

I hope I'm answering it clearly for you but if not, please let me know. 

[David Fischer]

So if I understand correctly, what you describe by "first" subtask is actually simply the first subtask that reaches the Done status, right? 

Now, I still don't understand your objective. Before any subtask reaches the Done status, the status of which subtask should the parent issue track?

Can you explain, from a functional standpoint, what you're trying to achieve?

[Dimitry Chewski]

Yes, that is correct for the "First" subtask. Currently, I have the flow setup to transition the parent issue based on the transitions of the subtasks. So if subtask is "In Review" the Parent transitions to "In Review" except for "Done" which the Parent issue won't transition to until all other subtasks are "Done".

What I'm trying to achieve functionally is when the "first" subtask reaches done, I want the parent issue to change it's status to the current status on the second subtask. So like the screenshot provided, the first subtask is "resolved". I want that transition to kick off the parent transition to the "Waiting for User" like the second subtask. 

Damien

[David Fischer]

Ok, let me try to summarize this using a simplified case.

Let's assume that:

- your workflow has 4 statuses: A, B, C, D and E, and global transitions to each status: To A, To B, To C, To D and To E that each takes issues to the desired status from any other status

- TEST-1 is a "parent" issue, and TEST-2 and TEST-3 are its two subtasks

- all three issues start at status A

My understanding is that, when TEST-2 moves to status B, you trigger "To B" on TEST-1, which takes TEST-1 to status B.

Then, imagine that TEST-3 also moves to status B. Transition "To B" is triggered again on TEST-1 but does nothing since TEST-1 is already in status B.

Now, let's imagine TEST-3 continues to status C and then D. This will trigger "To C" and then "To D" on TEST-1, which will leave TEST-1 in status D.

First question: what happens when TEST-2 then moves to status C? It triggers "To C" on issue TEST-1, does it move TEST-1 backward from status D to status C? If not, what's preventing it? Are you using regular transitions from one status to the next instead of global transitions?

Now, let's assume TEST-2 is in status C, and TEST-3 in status D, and TEST-1 in status D. TEST-3 moves to status E, which is your "Done" status. Instead of moving TEST-1 to status E as well, you want to move it to TEST-2's status, which is currently "C". Correct?

Then, when TEST-2 will eventually move to status "D", it will trigger "To D" on TEST-1 and thus move it to status D. And when TEST-2 reaches status E, TEST-1 will be moved to the status of TEST-3 which is already "E", so TEST-1 will end up on status E. Correct again?

To be honest with you, this is not something that's easy to do with Jira, because you cannot simply "write" to the Status field. But it can be achieved. However, it will require a lot of transitions, a lot of Transition Parent Issue post-functions and a lot of conditional execution scripts. And that's beyond the scope of what I can offer to help you with. I recommend you get (paid) help from an Atlassian Solution Partner.

[Dimitry Chewski]

This is exactly it David. Thanks for your time. I just wanted to know how feasible this could be with my abilities and it seems like it's unlikely.

Thanks again for your time as well as Earl's. I would consider this resolved on my half. 

[Earl McCutcheon · Accepted solution]

Hi Damien,

Check out this post , it has a breakdown and examples on how to do this.

Regards,
Earl

[Dimitry Chewski]

Thanks Earl, this is what I was looking for to get me on the right direction. 

Damien

[Dimitry Chewski]

So I jumped into that rabbit hole and realized that most of those scripts require ScriptRunner. Is there any chance you would know if this is doable with just Jira Misc Workflow Extensions add-on?