Task due dates update Epic due date

[Lee Tarter]

Hello, I run this code and get and error in my compare two values. It does not like me second value being 0 I believe and help would be great!

[Bill Sheboy · Accepted solution]

Hi @Lee Tarter -- Welcome to the Atlassian Community!

Without seeing the details of your Edit Issue Fields action, it is unclear what you are trying to do.  Is this what you are trying to do:

GIVEN an Epic issue which has one or more child issues
WHEN the Due Date changes in a child issue
OR WHEN the Start Date changes in a child issue
THEN update the parent Epic's Due Date to be the latest Due Date from its child issues
AND update the parent Epic's Start Date to be the earliest Start Date from its child issues

And, you do not state what you want to do in the cases of:

• all of the child issues have an empty Due Date field and the Epic's Due Date is not empty
• same as above for the Start Date

Let's assume those cannot happen...

For this scenario, none of conditions or extra expressions on the lookup JQL are needed.  Instead use the max and min functions on the date fields:

• trigger: Due Date or Start Date change
• condition: issue type does not equal Epic
• condition: parent is not empty
• branch: to parent
  • action: lookup issues with JQL of
    • parent = {{issue.key}}
  • action: edit issue
    • set the Due Date to {{lookupIssues.duedate.max}}
    • set the Start Date to {{lookupIssues.Start date.min}}

Note this could also run if you use Sub-tasks, so perhaps change that first condition to look for exactly the issue types which can be children of your Epics.

Also, I agree with Trudy to use two separate rules (rather than combining as I show).

Two more ideas...as written, your rule handles changing the date fields of existing children in the Epic, but not the other cases.  If you want to handle those also, additional rules with different triggers will be needed (using mostly the same logic):

1. When the Start Date or Due Data change in a child issue, update the Epic (This case is covered above.)
2. When a new child issue is created for an existing Epic parent...
3. When an issue's parent is set to become a child for an existing Epic...
4. When the parent of an issue is cleared, update the Epic for the remaining child issues  (This is a special case of #3 above.)
5. When an issue's parent is changed, update both parent Epics  (This is a special case covering both #3 and #4 above.)
6. When an issue is deleted from Jira, update the Epic for the remaining child issues (This is a special case of #4 above, and...hopefully, your Jira Site Admin has disabled issue-delete so this one cannot happen.)
7. When someone manually changes the Epic's Due Date or Start Date, and thus the values are no longer calculated from the child issues

Finally, if you need to handle empty / non-empty values for the child issues, a conditional expression could be used when the Epic's existing date values should be retained.

Kind regards,
Bill

[Lee Tarter]

Good Morning Bill! Thank you for the feedback. I made a rule based on your bulleted items and its working for now. I will most likely add cases for the numbered items like you said later, but for now its doing what I need.

Thank you all for the help!

[Trudy Claspill]

Hello @Lee Tarter 

Welcome to the Atlassian community.

If the Lookup Issues action doesn't find any issues then the size attribute may be null rather than 0.

When using that attribute in conditions it is a best practice to use it this:

{{lookupIssues.size|0}}

That says to use the size attribute value if it is a number, and otherwise use the value 0 in the comparison.

[Lee Tarter]

Hello,

Thank you for the feedback.

I changed the value to what you had and I get the same error. "the following issues did not match the condition.

MY bigger problem now is when I remove the compare part of the rule, the edit part of the rule just removes my due date for the epic.

Any thought on why this happens?

{{lookupIssues.last.Duedate}}

That is what I have in the edit issue field at the end for due date

[Trudy Claspill]

Please share with us the following:

1. New screen image of your rule so we can see the change you made.
2. The complete output in the rule Audit Log from when the rule ran. 

[Lee Tarter]

[Trudy Claspill]

Looking at the log output prior to the message that the issue doesn't pass the condition is the message that the Lookup Issues action is not finding any issues. If no issues are found the the condition doesn't pass.

When a condition doesn't pass none of the subsequent steps will be executed. So if your condition looking for child issues with Star dates doesn't pass the the action to doo a Lookup for Chile issues won't be executed.

You could use two separate rules; one for Start date and the other for Due date.

Or you could have two parallel branches in this rule where one executes the Lookup for Start date and the other executes the Lookup for Due date.

[Lee Tarter]

Unfortunately, This is the entire rule. So I do not think that is the problem.

I guess the lookup is the problem. The goal of the lookup is to order all duedates under the epic that a due date was modified, in order from furthest away to soonest, then the edit pulls the first duedate, the furthest away, and sets the epic due date as that

[Trudy Claspill]

With the above rule you are getting this output?

If you manually execute the JQL from the Lookup, substituting in the actual issue key of the Epic, do you get a list of the child issues?

It could be that the rule is running the lookup before the changed due date has been written to the database. Try adding a Re-fetch Issue Data action after the trigger.

[Lee Tarter]

If I remove the compare two values portion. I deletes the due date of my epic(parent) issue.

Any help would be amazing