nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to set automation to edit tasks/sub-tasks of Epics (i.e., all child issues)?

Ahmet Fatih Ayyıldız

This automation will help me edit all Child issues of Epic, whether tasks or sub-tasks, when the specific field of Epic changes.

Further context:

It is related to my Issue Security needs. Epics (and their child issues) will be visible to only the selected people who frequently change.

Since Issue Security applies to all tasks/subtasks of that Epic, I need automation to edit the "User Picker" custom field for all Child issues when the same field in the Epic changes. Whoever is in this custom field will have access to view all tasks.

But I need help getting this automation to work for sub-tasks. It only works for tasks.

Even when I change the "For Children" branch to "For Sub-tasks," it doesn't work.

I am lost in understanding why Epics and their parent/child relations cause so many problems at every step of my journey. I am trying to remember a scenario where the Epic's structure felt complete.

Accepted answers

John Funk

Hi Ahmet,

I think the problem lies in fully understanding the structure. Tasks are children of Epics. Sub-tasks are children of Tasks, not Epics. I guess you could say they are grandchildren. So the automation is only going to go one level deep.

You can accomplish this by creating a second rule where the Condition is for Task (and Story or any other Level 0 issue type).

So when the Epic fires, it will update all of the child tasks. This will trigger the second rule based on the Task getting updated and will update all of the Sub-tasks. Make sure the box is check on the Rule Details page to allow the rule to be executed by another rule.

All comments

John Funk

Hi Ahmet,

You can accomplish this by creating a second rule where the Condition is for Task (and Story or any other Level 0 issue type).

Ahmet Fatih Ayyıldız

Thank you, John; I think I get it.

I would have loved to solve this under only one rule, though.

Bill Sheboy

Hi @Ahmet Fatih Ayyıldız

Adding to John's answer, and following up on your note about trying one rule:

That may be possible, although it is a bit more complicated. There is a limitation that this can only work for up to 100 issues. If you have more, please use the 2-rule approach John describes.

The idea is to gather the all keys of the impacted issues first, and then use a JQL branch over them. This can be done using the lookup issues action. For example:

trigger: your field changed
condition: issue type is epic
action: lookup issues, with JQL to find the child issues of the epic
smart value condition: confirm there were results in the lookup
branch on JQL:

key IN ( {{#lookupIssues}}{{key}}{{#subtasks}}, {{key}}{{/}}{{^last}}, {{/}}{{/}} )

action: edit the issue's field

That smart value expression in the JQL grabs a child issue key, adding any subtask keys. Please look here to learn about list iterators: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#Combined-function-examples

Kind regards,
Bill

Ahmet Fatih Ayyıldız

Hello Bill, thank you for your detailed answer.

I will definitely look into it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-work-management

jira-work-management-cloud