Is there a way to use automation to automatically update the start and end dates of epics based on their subtypes, Story and Sub-task dates?I want my stories and sub-tasks to have the earliest and latest start/end dates updated in epic dates.
Yes, it is possible to update a parent Epic with the earliest Start Date and the latest End Date from among its child issues.
Within the For Epic branch you would use a Lookup Issues action to look up all the child issues of the Epic that don't have an empty Start Date value.
Then use {{lookupIssues.Start date.min}} as the smart value to get the earliest date from among the result set. Use that smart value to update the Start date of the Epic.
Use another Lookup Issues action to look up all the child issues that don't have an empty End date.
Then use {{lookupIssues.End date.max}} as the smart value to get the latest date from among the result set. Use that smart value to update the End date of the Epic.
Where I have used the "Add value to log" is where you would use the Edit issue action to update the Start date and End date fields of your Epic. (Also, I used Due date rather than End date).
Note that this picks up the information from only the direct child issues of the Epic. It doesn't consider the subtasks under the issues.
Jira doesn't natively support a method for getting all the subtasks of a dynamically generated list of issues. Without a third party app you can't get both the Epic child issues and their subtasks in one Lookup Issues action.
If you want to consider subtasks I would recommend doing a similar rule to the above to automatically update a parent issue's dates based on its subtasks.
Hi @Trudy P Claspill
It is possible to gather up the issues and their subtasks in one query with a rule...but it is often not practical because of the automation processing limits. For example, the 100 issue limit for Lookup Issues and the execution time limit (depending on what needs to be done).
Let's assume we know there are fewer than 100 total things for issues and subtasks. We can do this:
key IN ( {{#lookupIssues}}{{key}}{{#subtasks}}, {{key}}{{/}}{{^last}}, {{/}}{{/}} )
That variable will iterate over the first lookup with a nested iterator over the subtask attribute.
Kind regards,Bill
UPDATED: I removed the conditional on subtask as that did not consistently work, and appears not to matter as the nested iterator collapses to null when subtasks is empty.
I love that I am always learning new things through this community!
Thank you, @Bill Sheboy !
Indeed! This question reminded me I had solved this last year, could not find my test rule, and so had to re-create / re-learn the method :^)
It looks like you're new here. Sign in or register to get started.
