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; } } }

jira automation lookup

Thies Uhlenbruch

Hey,

in my automation I have a simple rule to lookup the child issues from one epic and set the epic due and start date according to the child issues (dates min/max).

That is working for a single epic. How can I advance the automation to define a jql with more epics so the all processed in this way?

Kind regards,

Thies

Accepted answers

Hauke Wollentin

You could try to fetch the Epics and put your actions into a branch rule, like this:

Screenshot 2023-02-07 at 13.51.21.png

Smart values of the Epics than are accessible via `{{triggerIssue}}`. You can find example inside the branch rule itself.

Have a good one,
Hauke

All comments

Hauke Wollentin

You could try to fetch the Epics and put your actions into a branch rule, like this:

Screenshot 2023-02-07 at 13.51.21.png

Smart values of the Epics than are accessible via `{{triggerIssue}}`. You can find example inside the branch rule itself.

Have a good one,
Hauke

Thies Uhlenbruch

Hey @Hauke Wollentin

Its the other way around :-)

With your example branch, it will edit the tasks of the epic. Thats not my usecase.

I want to lookup issues per epic and take the due and starte date from that and write it in the epic

Cheers,

Thies

Stefan Salzl

Hi @Thies Uhlenbruch

technically I understand what you want to do, logically I don´t:

An epic will potentially have several child issues. So the lookupIssues action will deliver a list of child issues. They all can (and potentially will) have different min/max dates.

So according to this it makes sense if you want to copy any field from a parent to a child (as there is a 1:n relation) but how would you validate from which child a field should be copied to the parent as the relation is the other way round --> n:1 ??

I guess it can be done technically but I guess the automation rule will always take the date of the last child issue of your lookupIssues and write it to the parent. As said: this might be technically correct but keeps big potential for wrong results.

Best
Stefan

Hauke Wollentin

Ah sorry, it should work also the other way around, but as @Stefan Salzl mentioned there could be pitfalls, since a logic like "take the latest due date of the issues in an Epic" isn't easy to implement - maybe it's impossible - with just Jira automation.

If you have ScriptRunner installed maybe a custom class or method would make sense to solve such approaches.

Thies Uhlenbruch

Hey @Hauke Wollentin

its possible and I made it:

some trigger (manual or scheduled). I used the scheduled one and put epics in a jql
a branch for the current issue
action: lookup issues parentEpic = {{trigger.issue}}
action: edit epic issue fields with {{lookupIssues.dueDate.max}}, {{lookupIssues.startDate.min}}

Works fine :-)

Isaiah John

Guys, I just learned you can use the "scheduled" trigger to do a JQL Query. All issues returned will be treated as trigger issues. You could then use the "For: Sub-tasks" branch then a status condition to act on their sub-tasks.

Screenshot 2023-08-11 094501.png Screenshot 2023-08-11 095256.png

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

epic

automation