Automation: Trigger when child removed from Epic

[Karin_Gleichauf]

I built an automation to set epics "done" when all  children are "done". When a new task becomes child by adding the epic  link the epic is again set to "in progress".

When the epic link is removed on the task (so there is no more child in the epic not "done") the epic should be moved to "done" again, but I can't find the proper trigger for this rule.  (Don't like to use a scheduled rule to check whether all children are done in an epic).

Has someone an idea how to solve this?

Best regards

Karin

[Trudy Claspill · Accepted solution]

It is possible to create a rule that is triggered on Issue Updated and then check the change log to see if it was the Epic Link field that changed, and pull the before and after values of the field. From there you would be able to get back to the Epic and evaluate the status of the child issues.

Note though that the rule would be triggered on every issue update. You can zero in on the Epic Link in the trigger itself.

The response from @Bill Sheboy on this post discusses this.

[Karin_Gleichauf]

Hi Trudy,

thanks a lot! When I have received the issue-key of the Epic by {{#changelog.epic link}}{{fromString}}{{/}}, how can I branch my rule to evaluate the status of the child issues of that epic and not of the trigger issue?

Best regards 

Karin

[Mark Segall]

You can use a JQL branch:

Key = {{#changelog.epic link}}{{fromString}}{{/}}

[Trudy Claspill]

@Karin_Gleichauf 

@Mark Segall and I were talking this over, and came up with this solution.

TRIGGER: issue Updated

CONDITION (Advanced):

  - {{#changelog.epic link}}{{fromString}}{{/}}

  - Does not equal

  - {{#changelog.epic link}}{{toString}}{{/}}

BRANCH (Advanced): varEpicLink

  - {{#changelog.epic link}}{{fromString}}{{/}}

  - CONDITION

    - status != Done

  - ACTION: Lookup Issues

    - "Epic Link" = {{varEpicLink}} AND status != Done

  - CONDITION (Advanced)

    - {{lookupIssues.size}}

    - Less Than

    - 0

  - ACTION: Transition Issue to Done

[Karin_Gleichauf]

Hi @Trudy Claspill  and @Mark Segall ,

thank your very much for your effort!

I still have the problem that the Conditions in the branch don't check the Epic but the triggering Task:

(MMA-5658 is the Task in my Epic MMA-5655)

[Mark Segall]

That's odd.  Let's try replacing the condition with this so it's more explicit about what it's performing the condition against:

• Advanced Condition

  • {{varEpic.status.name}}
    Does Not Equal
    Done

[Trudy Claspill]

@Karin_Gleichauf 

I worked through testing the above rule and could not get it to work properly as written. But I was able to construct an alternate rule and tested to prove that it does work. 

Using the same trigger and first Condition, I added a second Condition.  This rule would be triggered if an issue was added to an Epic also. In that case we need to abort running the rule if the issue was not previously assigned to an Epic. In that scenario of no previous Epic, the rule would fail with an error, so we'll proactively abort in that scenario with this second condition.

For the branch, we'll use Advanced Branch/Related Issues/JQL

This will retrieve the Epic to which the issue was previously assigned.

Within the branch we:

1. check that the status of the previous Epic is not Done. We'll exit the rule if the previous Epic status is already set to Done.

2. Use Lookup Issue to find any child issues of that Epic that are not in a Done status.

3. Check that we did not find any not-Done children. If we find not-Done children we'll exit the rule.

4. And finally, set the previous Epic status to Done if there were zero not-Done children.

[Karin_Gleichauf]

Hi Trudy,

thank you so much! Everything is running perfectly  now. Great work!

[Mark Segall · Accepted solution]

Hi @Karin_Gleichauf 

Since we're not able to perform JQL against historical Epic Links, it will not be possible to key off of a previous Epic association.  For example, you would need a function that simply doesn't exist:

• TRIGGER: Field Value Changed (Epic Link)
• BRANCH Previous Parent

So, you have to go at this from the epic itself and that means a scheduled rule is unfortunately really the only way to go because there is similarly no ability to trigger when child issue added/removed

I hope this helps explain why the scheduled trigger is really the only option.

[Karin_Gleichauf]

Hi Mark,

thank you very much. I hoped for a trigger like "issue link deleted" but expected there is none for the epic-child-relationship. So I will have to go for the scheduled rule.