Using automation to get the Epic of a Sub-Task (Parent of a Parent)

[Halley Nikolak]

Does anyone one know how to get the Epic associated to a subtask without using the "Epic (parent)" branching rule (as it will be demised in the near future)

I am able to create a rule to the parent (story), however I would also like to perform actions to the Epic related to that story, but it does not seem possible to branch and retrieve the parent of a parent.

The overall goal I am trying to accomplish is to create a rule so when changing the Subtask status from to-do to in-progress, the Story above, and the Epic will also be updated to the same status

Thanks

[Bill Sheboy]

Hi @Halley Nikolak -- Welcome to the Atlassian Community!

The actions for the grandparent of the subtask (i.e., the epic) impact what is needed:

• If you are trying to edit it, the rule will need to branch to it, probably with JQL
• If you are only trying to read field data from it, you could use Lookup Issues with JQL to get to it

The reason for this need is if all the rule smart values / links worked through all levels, pulling all the field data, the tree could contain a large number of issues.  Such as:

{{issue.parent.parent.parent...}}

Reviewing the available smart values for an issue with a parent, using the how-to article below, you can see only a subset of the data for a parent is provided with an issue: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

I believe it is possible to create one rule, which triggers itself, to make the updates you describe.  But that could lead to looping errors.  Instead you may want to create two rules: one for the subtask/Story parent interaction and that triggers the second rule for the Story/Epic interaction.

Kind regards,
Bill

[Majken Longlade]

I'm also trying to do something with an Epic when something changes in either a sub-task or a story. In your case, you know you have a sub-task, and then you want to do something to the parent and then to the Epic, so I think branches will work.

In my case, I want to perform the same action on the Epic when either a story or a sub-task has changed. Since you cant use info from branches in the main rule or future branches, I can't use branches to say "if it's a story look up the epic this way, if it's a sub-task look it up this other way" :-\

[Bill Sheboy]

Hi @Majken Longlade 

First thing, as this is an older thread I recommend creating a new question, and perhaps linking back to this one for context.  That will ensure the maximum number of community members see it to offer suggestions.  Thanks!

Back to your question...

Yes, that is still possible.  A rule which needs to update an Epic based on a change to a child issue (e.g., a Story) or a "grandchild" (e.g., a Subtask of a child Story) could use conditions to select how to branch to the Epic.

Kind regards,
Bill

[Majken Longlade]

Hi @Bill Sheboy ,

Sorry, I'm behind on my notifications, didn't see you'd replied! I don't know what you're suggesting. I want one branch to update the epic, how would I write the rule before that? 

[Majken Longlade]

Ooh, I think I figured it out! Need to use a lookup table with two entries, one with the key true and value {{issue.parent.parent.key}} and one with key false and value {{issue.parent.key}} 

I called the table findEpic

Then I can advanced branch on the smart value {{findEpic.get(issue.issuetype.subtask)}} I do a smart values condition to make sure {{findEpic.get(issue.issuetype.subtask)}} is not empty and then I do a JQL branch on key = {{findEpic.get(issue.issuetype.subtask)}}

For Halley's case she could also do one branch on JQL where the JQL is key in ({{issue.parent.key}},{{issue.parent.parent.key}}) and the action is to transition the issues to match the trigger issue.

This JQL doesn't work in my case because it errors out when a standard issue is the trigger because {{issue.parent.parent.key}} is null

[Bill Sheboy]

Yes, and...as I noted originally: all data for all linked issues (i.e., parent, subtasks, and linked issues) is not loaded for each issue a rule accesses.  Instead the workarounds of branches, lookup issues, or REST API calls are needed to get at the information.