Premise: to update epic due date to align with latest due date of child user stories.
Trigger: field due date of any of constituent user story is changed.
Condition: IF current epic's due date is different to max due date of ANY child user story (including the triggering issue and it's new value), THEN update the epic to the max value.
Comment: This should work for both extending or shortening the overall epic's duration based on changed to user stories in it. I could apply the same for star dates.
I need to know how to target all child items of a parent of a current (triggering) issue, and how to perform max/min check on this.
Hello @Rafal Wzorek
Welcome to the Atlassian community.
After your trigger add a brach - For Each: Related Issue: Parent
That will change the focus to the parent issue of the trigger issue.
Within the branch use a Lookup Issues action to execute a search for all the child issues of that parent using JQL
parent={{issue.key}} and "Due date" is not empty
Then you can find the max or min of a date field in the returned issue using the min and max functions:
{{lookupIssues.Due date.max}}
You can compare that to other values (use the Smart Value condition) and use it to set the value of a field in an Edit action.
You can see an example of this on my answer to this other post:
That's great. I have edited this reply few times, but it boils now to 2 things. I was able to make it "work" whereby updating any child would update the parent epic (using Timeline view, which is great), however:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you provide screen images that show the complete rule and the details of each step?
And can you provide the details from the rule execution Audit Log entry for executions where something unexpected happened?
An excellent debugging tool is the Log action. With the Log action you can print information into the Audit Log during the rule execution. I use this liberally to print out the current values in issue fields and to print out any other smart values I'm using. It helps me confirm that the data in those fields/smart values is what I expect it to be. If you are trying to print out issue field values after steps where the values were changed make sure that you add a Re-fetch Issues action to get the current information for the issue first.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for following up. First I wanted to reconcile smart value variables. I've added log action as per below but I don't see the results in Action log (in the Automation section, or is it the wrong place?)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As for the current flow and the actions I have the following. The IF conditions results in no matches, when I remove it it runs and makes parent due date blank.
I wrote a lengthy response but I realised the culprit is probably an incorrect "duedate" field I am using in the initial lookup - a field simply called "duedate" - which is probably incorrect/blank, thus all the results are not working and parent is updated with max value among blank values, also blank!
In "Edit issue" where I can choose field from the list, there is "Due date (System)" and "(Due date (datepicker)" (I use the first one which seem to update the right field). In JQL, I see suggestions for "Due", "duedate", and "Due date", and the first two work as expected (last one may be from a plugin).
So I wonder if they are called the same in smartvalues - although checking documentation it appears it's just "duedate":
{{issue.duedate}} - Returns the issue's due date
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The cause of the problems seems to be there are multiple fields with the same name causing confusion in rule processing. What is the purpose of the added custom field?
Additionally, the built-in "Due Date" field has multiple smart values that work in rules and so that could cause further confusion with that extra field.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.