How to use Automation to update Epic issue links based on "owned" issues

[Alfred Sawatzky]

Does anyone have any pseudo code ideas for an automation script that does the following?

Update an Epic's issue links (e.g., depends on, relates to, blocked by, etc.) to other Epics based on the issue links of all issues "owned" by that Epic?

For example, I have Epic A which has the following issues:

1. issue 1
   • depends on issue 3 (which is part of Epic B)
2. issue 2
   • is blocked by issue 4 (which is part of Epic C)

Based on an automation trigger event on Epic A, I would like it's issue links to end up being:

• Epic A depends on Epic B
• Epic A is blocked by Epic C

I am doing all this because of my Aha/Jira integration.  In Aha, I would like to see how the Aha features (aka Jira Epics) depend on each other.  But engineers in Jira don't typically set up issue links for Epics.  They set up issue links for Tasks, Stories, Bugs, etc.  So I need a way to automate Epic link relationship updates to pass those through to Aha.

[Bill Sheboy]

Hi @Alfred Sawatzky 

In your example, does "Issue B" = "Epic B" and does "Issue C" = "Epic C", or is that a naming coincidence? 

For example, I have Epic A which has the following issues:

1. issue B
   • depends on issue D (which is part of Epic B)
2. issue C
   • is blocked by issue E (which is part of Epic C)

Best regards,
Bill

[Alfred Sawatzky]

Hi @Bill Sheboy.

Sorry, that was a bad naming coincidence.  I did not take into account that in Jira Epics are actually a type of issue.  I have updated the description to clarify the confusion. 

Regards,

Alfred

[Bill Sheboy]

Thanks for clarifying, Alfred.

My short answer is: this may be possible with automation rules, but I would not do it out of concerns for implementing, testing, and looping to create redundant links. 

Longer answer:

At this time, I do not believe you can nest automation branches, so this might take at least 3 interlocking rules and custom fields to progressively walk down the chain, and then back up to the top to update the original epic.

• Walk the first epic to find the first-level children, marking them as needing a scan to trigger the next rule
• Walk the first-level children to find the linked issues, and gather their epics into a custom field list
• Re-walk the first epic to add links from the custom field list

I could see lots going wrong with this approach, and I welcome any ideas others have for how to simplify this using automation.  I just recreated your use case in a company-managed project to see if the Basic Roadmap could help, and without the epics linked that does *not* show those dependencies.

Sorry I could not be of more help.