Move multiple due dates automatically for issues within the same epic

[Emanuel Pinkwart]

Hi Community,

I have a question regarding automation rules for changing due dates. We are using Kanban Software projects (no sprints nor versions / working with start date and due date / estimates field is filled )

Would it be possible to create a rule that is triggered by one issue with a due date change and have that change be reflected to the other issues within the same epic? Two examples:

A) Let's say I just want the new due date to automatically be copied over to the other issues in the same epic.

B) More complicated: I want the new due dates for each issue (within the same epic) to be automatically calculated and moved by X days. X stands for the delta value of due dates from the triggering issue  ( = new due date - previous due date).

Is this possible in Jira using the automation rules and regular JQL? Or will it require add-ons such as Script Runner or others?

TIA

Emanuel

[Bill Sheboy · Accepted solution]

Hi @Emanuel Pinkwart 

Both of your use cases sound possible with out-of-the-box JQL and automation for Jira.

You do not state if you are using a company-managed or team-managed project, as that impacts how issues are linked (epic to children).  For both project types, you may try something like this:

• trigger: detect the due date change
• condition: issue type is story
• condition: epic link is not empty (or check parent for team-managed)
• (for your second use case) action: compute the delta date change using changelog
• branch: walk the sibling issues for the trigger issue
  • action: update the due date

Please take note to consider edge cases: to/from empty trigger issue's due date, sibling issues have empty due date, handle already completed issues, due dates moved earlier (not later), etc.

Kind regards,
Bill

[Emanuel Pinkwart]

Thank you very much Bill. We are using company managed projects. 

I tried to build this rule from scratch (see below) but are still not sure how to make this work. The error message I am getting right now is: "No related issues could be found". What should be the condition to find the other issues in the same epic?

And once this works, for my second use case (B), how do I compute the delta and write it into each of the issues? Do you -or anyone else - have an example?

Thanks a lot, Emanuel

[Bill Sheboy]

Gotcha...that branch you are using, "For Stories (or other issues in Epic)", works when the trigger issue is an epic.

And it seems you want the siblings of the trigger issue (a task) for the same parent epic, correct?

If so, you would instead use JQL to do the branch, such as:

project = myProject AND "Epic Link" = {{triggerIssue.Epic Link}}

[Emanuel Pinkwart]

Hooray, that worked. I am now able to set the due date for all siblings automatically (copied from the trigger issue).

I am still trying to figure out the second use case. Any idea on how exactly the computing formula will look like and where to enter it? 

B) I want the new due dates for each issue (within the same epic) to be automatically calculated and moved by X days. X stands for the delta value of due dates from the triggering issue  ( = new due date - previous due date).

Will I require two formulas? One to calculate the X value and write it into some field or variable? And a second formula that calculates the new due date for each sibling issue based on X, including a last step that sets that value as the new due date. 

Thank

[Bill Sheboy]

Your second case is quite the coincidence, as someone else just reminded me I already solved this.  :^) 

Please see this thread for how to use the fieldChange log to compute that difference:

https://community.atlassian.com/t5/Jira-Software-questions/fieldChange-from-does-not-work-inside-compound-statements/qaq-p/1794888

Now comes the bonus: since that post, Atlassian has improved created variables in rules so they can now be used in functions.  What that means is you may compute the delta-date, save it in a variable, and then use it repeatedly in your rule for adjustments.  That will help with testing and cut down on entry/copy-and-paste errors.

Please take a look and let me know if you have questions about this approach.  Remember to consider any edge cases:

• going to/from an empty date
• handling the same date, but someone has put in a time value
• etc.

[Emanuel Pinkwart]

Thanks a lot, the following from your other post did the trick:

{{issue.dueDate.plusdays(fieldChange.from.toDate.diff(triggerissue.duedate).days)}}

Thank you very much!