Child Start and Due min/max dates to roll up to parent

[ckopanon]

I am running into an issue with automation to have the child min and max start and due dates top roll up to the parent start and due date. It seems to be pulling the due date no problem but it's not pulling the start date. 

[Bill Sheboy]

Hi @ckopanon 

Start Date is one of the date fields which appears as text to automation rules...similar to other roadmap fields.  The workaround for your scenario is to convert the value with the toDate function  before attempting to use the min function, and then convert back to the necessary date format as text.

For example:

{{lookupIssues.Start date.toDate.min.jiraDate}}

Please see updates below...

Kind regards,
Bill

[Trudy Claspill]

@Bill Sheboy 

Is that documented somewhere by Atlassian? I'd like to bookmark that for future reference.

I thought I remembered that min and max did not work for all date fields, but did not find the details in my quick internet search.

[Bill Sheboy]

Hi @Trudy Claspill 

I recall discovering that symptom by experimentation with Start Date and Target End...although I just tested again and {{issue.Start date}} worked as a date without conversion.  Thus, something has changed over time, and the text format is not the cause of the symptom seen by @ckopanon 

Either a duplicate field or rule scoping are likely causes.  (i.e., is the rule in the HI project as shown in the JQL, and should it instead refer directly to the parent)

Regarding the min function, date and date / time picker fields are essentially a number, and thus the min function will work on either one correctly.  The JPD date format is JSON-as-text, and will not work with min until a value is converted and extracted.

Thanks for keeping me honest to test my suggestions before posting!

Kind regards,
Bill

[Bill Sheboy]

Hi @ckopanon 

Please review the earlier posts in this thread where I describe your Lookup Work Item action's JQL does not reference the parent...and thus you may be looking at the wrong work items.

Within the branch, if you wanted the lookup to use the parent, the rule would look like this:

• trigger: field value changed, for Start Date or Due Date
• field values condition: issue type is one of Story, Bug, Task
• branch: to parent
  • action: Lookup Work Items, with JQL of
    • parent = {{triggerIssue.parent.key}} AND "Start date" IS NOT EMPTY AND duedate IS NOT EMPTY
  • smart values condition: 
    • first value: {{lookupIssues.size|0}}
    • condition: greater than
    • second value: 0
  • action: edit work item, setting the fields with:
    • Start date: {{lookupIssues.Start date.min.jiraDate}}
    • Due date: {{lookupIssues.duedate.max.jiraDate}}

Thanks,
Bill

[ckopanon]

hello,

i set this up exactly how you have it listed and unfortunately, no dice. This time though its not pulling the due date either.

[John Funk]

Can you share the full rule that is the latest? 

[ckopanon]

[John Funk]

So which field did you change on the trigger to get it to fire? 

And neither field got updated? 

You might want to log the lookupIssues.size to see what the value is. 

[Bill Sheboy]

Please post the audit log details showing the rule execution after your changes.  This will confirm which work items the rule attempted to process.

And just to confirm, are all of the work items involve in a single space / project: the parent and the children?

[Trudy Claspill]

Hello @ckopanon 

Can you tell us the type of Space this concerns? Click on the ... next to the Space name in the navigation panel on the left and tell us what the last two lines say. That will be something like:

Software space
Company-managed

Has this rule ever worked previously?

It is possible that there is more than one field in your system named "Start date" and the rule is not getting the correct one within the Edit Work Item action. An alternative method to set the value would be to use the custom field id instead of the custom field name as the reference; i.e.

{{lookupIssues.customfield_11111.min}}

You would need to find the correct ID for that specific "Start date" field. This document explains how that can be done.

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[ckopanon]

yes, software space, company managed.

this is the first time the rule has been created and run so no, it has not worked for start date ever. only works for due date currently.

i did try this with the Start date custom field ID and still did not work.

[Trudy Claspill]

Field names are case sensitive in smart values. Can you confirm that you have the case correct for the "Start date" field?

As a test in the rule can you add a Branch to iterate over the Lookup Work Items results and use the Log action to print to the execution log the value from the "Start date" field for each item?

[ckopanon]

yes, i can confirm i have the case correct. 

i added the branch and it looks like the log is only showing the start date for the child work item 

[Trudy Claspill]

Can you show us images of the modified rule and the details that generated in the rule execution log?

[ckopanon]

Let me know if i have this wrong:

[John Funk]

Hey Chelsea - I hope all is well with you. 

Yes, the log is only showing the child start date because you are using triggerIssue.xxx - the trigger issue is the child issue. 

[ckopanon]

hi john, same to you!

if i remove trigger and just leave it as {{issue.customfield_10015}} the log is blank. I am just not understanding why due date is rolling up with no issues but start date is not.

[John Funk]

I don't see anywhere where you are matching the parent with the parent of the parent from the lookup issues. Take a look at Bill's last post for that. 

BTW - Bill and Trudy are the experts here, so if they can't help you, then you are beyond hope. haha. 

[Trudy Claspill]

Hello @ckopanon 

When sharing the log please click on all the ">" characters to the right of the message to expand/show all the details related to each of those sections.

Additionally, the Log action you added was not quite what I meant. My intention was to have the field printed for each item found by the Lookup Work Items. Since you can't nest one branch within another you would need to create a separate branch to iterate over the same items found by your Lookup action.

But what has also occurred to me is that the JQL in your Lookup is not correct. I see that @Bill Sheboy provided an example of the correct JQL to use.

Can you add to the response thread with Bill the details of the execution log for that version of the rule. And as I mentioned at the beginning of this reply, make sure that you expand all sections so we can see all the details.

In that scenario where you did not get the Due date updated either, I suspect that may be due to your JQL statement. It will return only child items where both Start date and Due date are filled in. I suspect that when you tried to use that version of the rule you may have gotten no items returned by the JQL due to none of the items having both fields filled in.

Where you were getting values before you were using a JQL that would return the same (items with both fields filled in) but you did not have the criteria for Parent set correctly. Your original JQL would've been returning items that did not have the same parent as the trigger item.