Hi there!
I am currently working on a automation project in which I need to send an email with certain informations from a list of lookupIssues tikckets. One of these informations is to get the difference between the fixVersion startDate and fixVersion releaseDate. To do so, I work with smart values. Here's the code:
{{#lookupIssues}}
{{fixVersions.first.startDate.diff(fixVersions.first.releaseDate)}}
{{/}}
(the .first is because fixVersions are lists but we are sure that there will always be only one fix version per ticket so it's fine)
As you can see, by code is pretty simple, with a lookupIssues list that contains for now two tickets:
1st ticket: fixVersion startDate is 17 June 2024, fixVersion releaseDate is 27 June 2024.
2nd ticket: fixVersion startDate is 14 May 2024, fixVersion releaseDate is 18 May 2024
As you can see, if you do the difference between the startDate and the releaseDate of each ticket, the result should be 10 for the first and 14 for the second. However, when I test this, the result is 10 and 44.
Here's the automation and the result.
The only thing I can notice here is that the code somehow does the difference between the startDate of the current ticket and the releaseDate of the first ticket, as the difference between May 14th and June 27th is in fact 44 days.
Keep in mind that I cannot use a foreach loop as I send an email that will be sent too many times in a loop. I don't understand why this doesn't work as expected, and why it semingly takes only the value from the first ticket in the list for the difference. Can anyone help me figure this one out?
Hi @Zoe Harris -- Welcome to the Atlassian Community!
First thing, this symptom appears to be a defect in the way automation rules handle list fields, like Fix Version, when using functions inside of iterators.
There are similar community posts for the Sprint field. If you are on a paid Jira license, I recommend working with your Jira Site Admin to submit a ticket to Atlassian Support so they are aware of it: https://support.atlassian.com/contact/#/ Make a copy of your original rule to provide to them context for the ticket. When you hear back from them, please post what you learn to benefit the community. Thanks!
Please note...complicated work-around ahead!
One complicated work-around, which is more challenging as you are trying to perform a diff() on two attributes of the field, forces the field list to split as you expect. If you want to try one possible approach, these assumptions apply:
If those match your case, you could try this expression.
{{#lookupIssues}} ticket key: {{key}}, start date: {{fixVersions.first.startDate.format("dd/MM/yyyy")}}, release date: {{fixVersions.first.releaseDate.format("dd/MM/yyyy")}}, difference between start date and release date: {{#=}}
( {{#fixVersions.releaseDate.join("~~").split("~~").first.toDate}}func=plusSeconds(0), format="toMillis"{{/}} -
{{#fixVersions.startDate.join("~~").split("~~").first.toDate}}func=plusSeconds(0), format="toMillis"{{/}}
) / (24*60*60*1000)
{{/}} days; {{/}}
How that works...
Kind regards,
Bill
Hello @Bill Sheboy
Unfortunately, I'm faced the same issue that Diff doesn't work properly in the lookupIssues loop. I've spent some time searching for the solution and end up here.
I tried to implement the solution you suggested, but for some reason I'm not able to get time in milliseconds by using this approach:
When I tried to apply math expressions, I got an error:
So I created a simplier automation with comment and manual trigger to debug it step by step. I'm using {{#last}} just to reduce number of results printed.
Here is my automation
The comment content:
Found by Lookup: {{lookupIssues.size}}
{{#lookupIssues}}
{{#last}}
start date: {{customfield_12413.format("yyyy-MM-dd")}},
release date: {{duedate.format("yyyy-MM-dd")}},
epoch start date: {{#customfield_12413}}func=plusSeconds(0), format="toMillis"{{/}}
epoch duedate: {{#duedate}}func=plusSeconds(0), format="toMillis"{{/}}
epoch try 1: {{#customfield_12413}}format="toMillis"{{/}}
epoch try 2: {{#customfield_12413}}toEpochMilli{{/}}
epoch try 3: {{#customfield_12413}}getMillis{{/}}
{{/}}
{{/}}
and the result I'm getting:
I suspect the issue is that I'm trying to get it from the Date picker, which is probably not a valid DateTime object. So it can't be properly converted "toMillis"
Could you please suggest how I can get it work?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @VolodymyrYu -- Welcome to the Atlassian Community!
What version of Jira are you using: Cloud, Server, or Data Center?
If you try those epoch value functions with a single issue, what do you observe? For example:
{{#issue.created}}format="toMillis"{{/}}
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.
We're using Jira Cloud
I've tried the following:
{{#issue.created}}format="toMillis"{{/}}
{{#issue.customfield_12413}}format="toMillis"{{/}}
{{#issue.duedate}}format="toMillis"{{/}}
And got next resutls:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tried following:
{{#issue.created}}format="toMillis"{{/}}
{{#issue.customfield_12413}}format="toMillis"{{/}}
{{#issue.duedate}}format="toMillis"{{/}}
and got next results:
1716700831047
2024-05-01T��:��:��.0
2024-06-09T��:��:��.0
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for trying that.
This symptom is caused because the Start Date and Due Date are date type, but that function appears to only work with date / time types.
A workaround is to format the values as jiraDate text and then convert back to date / time types:
{{#lookupIssues}}
{{#last}}
start date: {{customfield_12413.format("yyyy-MM-dd")}},
release date: {{duedate.format("yyyy-MM-dd")}},
epoch start date: {{#customfield_12413.jiraDate.toDate}}format="toMillis"{{/}}
epoch duedate: {{#duedate.jiraDate.toDate}}format="toMillis"{{/}}
{{/}}
{{/}}
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.