How to close other sub-tasks when parent is transitioned to DONE

[Sinisa Glusac]

Hello,

I'm working on this automation for my company but I'm stuck and need help.

Automation refers to closing all other subtasks when the parent transition is moved to "done".

For example, I created automation for a ticket that has 3 subtasks. If one subtask is canceled, then the parent is also closed. That works perfectly, but the other 2 subtasks stay open and I'd like them to automatically transition to "canceled" after the parent. 

There is a screenshot of the automation:

and this is automation for closing parent which works: 

There is no error log, as the problem is mostly not triggered, but I've tried everything to make it work, but no luck. It would be greatly appreciated if anyone could help. Thanks in advance!

Warm regards, 

Sinisa

[Trudy Claspill · Accepted solution]

Hello @Sinisa Glusac 

On the rule that tries to close sub-tasks when the parent is closed, on the Rule Details for that rule how do you have this option set?

I believe you will need to have this checked/enabled so that your rule to close sub-tasks can be triggered by the the actions of the rule that closes the parent issue.

[Sinisa Glusac]

Hi @Trudy Claspill

this option wasn't checked, and I did it now, but without any results. The rule is visible on the execution list and no action. Audit logs show this 

[Sinisa Glusac]

Hi, I've found the solution. The automation should be like this

Simple solution but it works!

Cheers!

[Trudy Claspill]

I believe the problem is here:

The "If: Some Sub-tasks match" condition is using the Related Issues Condition. However, since it is within the For Related Issues (Sub-tasks) branch, it is trying to look for Sub-tasks of Sub-tasks. You are effectively saying

For each Sub-tasks

- If the Sub-task has Sub-tasks and some of them have a status of Canceled...

Here is a rule that works. There may be a better way to do this, but this does work. I've broken it into pieces so I can describe each piece. Also, I'm using "Done" instead of "Canceled" for the Sub-task status.

1. Add a condition to check the issue type of the issue that triggered this rule to ensure it is not getting triggered by Sub-tasks that get transitioned to Done.

2. This is a step to help figure out if the issue that triggered the rule has an==y Sub-tasks that are in a Done status. In your case substitute "Canceled" for "Done" here. If you don't know about the Lookup Issues action, see the documentation.

3. This action will add a log message to the audit log for your rule telling you how many of the triggering issue's sub-tasks are "Done" (in your case "Cancelled"). The rule is going to use this value later, so it is good to log what the value is.

4. Start your branch for Sub-tasks of the triggering issue

5. Check if the previous Lookup Issues action found that the triggering issue has sub-tasks in the specified state (in your case "Canceled"). If none of the sub-tasks where in that state, then (based on what you posted previously) you don't want to change the remaining sub-tasks of the triggering issue.

6. Check the status of the sub-task being looked at within the branch. You don't need to change its status if it is already set to an acceptable status.

7. This is another log message for the rule's audit log. It tells you the issue key and current status for each sub-task that is not in the desired status already.

8. Finally, change the sub-task to the desired Status.

[Trudy Claspill]

@Sinisa Glusac 

Your simple solution will definitely work, however,

1. It will be triggered by any transition of the parent issue to Done regardless of whether or not any of the sub-tasks are already set to Canceled.

2. It will also transition to Canceled only the sub-tasks in that are currently in the status you specified (Waiting for approval) and will not transition sub-tasks in any other status (i.e. To Do) unless you add those other statuses to your list.

3. It will be triggered by any type of issue that transitions to Done unless you add a condition after the trigger to check the issue type of the triggering issue.

If each of those is acceptable to you, then your simpler solution is definitely the way to go!

[Sinisa Glusac]

@Trudy Claspill  that's true, but at the moment, this is what our company needs. However, I will make the automation you suggested and I will test it, if works for us, it will definitely be used. Thank you so much for your hard work and help, I really appreciate it!!!!

Cheers!

[Naveen Penta]

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.event.type.EventDispatchOption

import org.apache.commons.lang.StringUtils

import com.atlassian.crowd.embedded.api.Group

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.config.PriorityManager

import com.atlassian.jira.user.ApplicationUser

import com.opensymphony.workflow.InvalidInputException

    if (subtaskStatus == "Done" || subtaskField == "Low"){

      result.push(true)

    }

    else {

      result.push(false)

    }

}

log.warn(result)

if (result.contains(false)){

throw new InvalidInputException("Please closed all subtasks")

}

else {

  return true

}