Hi everyone,
I'm using JIRA Data Center(Atlassian Jira Project Management Software (v9.12.17)) and trying to set up an automation rule in Jira, but I'm running into a date parsing issue.
Here are the relevant fields I'm working with:
Field Name | Type | ID / Source |
---|---|---|
Target Start | Target Start | customfield_17971 |
Target End | Target End | customfield_17972 |
Estimates (d) | Number | issue.timetracking.remainingEstimateSeconds |
Both Target Start and Target End are expected to be Date fields. However, they show as “Target Start” and “Target End” under the Type column, which makes me unsure if they’re actually treated as Date fields.
When the Estimate is updated and Target Start is not empty, I want to automatically set:
Target End = Target Start + Estimate (in workdays)
My smart value expressions:
Variable for workdays:
{{issue.timetracking.remainingEstimateSeconds.divide(28800).round}}
Update JSON:
ALL OF FOLLOWING HAS THE ERROR:
{"fields":
{ "customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd).jqlDate}}" } }
{
"fields":
{
"customfield_17972": "{{issue.customfield_17971.jiraDate.plusBusinessDays(4)}}"
}
}
{
"fields":
{
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(4)}}"
}
}
I get the following error when the rule runs:
Error parsing date string: (customfield_17972
)
I’ve verified that customfield_17971
(Target Start) is not empty during testing. Any idea why the .plusBusinessDays()
or .jqlDate
part is failing here?
Appreciate any help or clarification on this — especially if there’s a better way to format or update Date fields using smart values in automation!
Thanks!
UPDATE:
Tired another syntax as follow
WORKS!
------------------------------------
{
"fields": {
"customfield_17972": "{{issue.customfield_17971}}"
}
}
{
"fields": {
"customfield_17972": "2025-10-10"
}
}
---------------------------------------
DOESN'T WORKS (same error:Error parsing date string: (customfield_17972
))
---------------------------------------
{
"fields": {
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd).format(\"yyyy-MM-dd\")}}"
}
}
{
"fields": {
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd.asNumber).format(\"yyyy-MM-dd\")}}"
}
}
---------------------------------------
And I noticed that this function:
plusBusinessDays()
Need an Integer for the parameter, so after reading this post: https://community.atlassian.com/forums/Jira-questions/Is-it-possible-to-use-a-smart-value-within-the-minusBusinessDays/qaq-p/1557511#U3072188
I tried to put log like this:
workdaysToAdd = {{workdaysToAdd}} \n
now = {{now}} \n
now format = {{now.format("yyyy-MM-dd")}} \n
issue.customfield_17971 = {{issue.customfield_17971}} \n
now.plusBusinessDays(1) = {{now.plusBusinessDays(1)}} \n
now.plusBusinessDays(1) format = {{now.plusBusinessDays(1).format("yyyy-MM-dd")}} \n
now.plusBusinessDays(workdaysToAdd) = {{now.plusBusinessDays(workdaysToAdd.asNumber)}} \n
now.plusBusinessDays({workdaysToAdd}) = {{now.plusBusinessDays({workdaysToAdd.asNumber})}}
Output as follow:
workdaysToAdd = 70 \n
workdaysToAdd asNum = \n
now = 2025-07-20T16:11:20.5+0000 \n
now format = 2025-07-20 \n
issue.customfield_17971 = 2025-07-25 \n
now.plusBusinessDays(1) = 2025-07-21T16:11:20.5+0000 \n
now.plusBusinessDays(1) format = 2025-07-21 \n
now.plusBusinessDays(workdaysToAdd.asnumber) = \n
now.plusBusinessDays({workdaysToAdd}.asNumber) =
So, what I suspect this far:
Smart value variables created using Create variable seem to be treated as Strings.
.asNumber is not supported in my Jira environment, so I can’t force the type conversion.
This may be causing plusBusinessDays(workdaysToAdd) to fail silently, since it's expecting a number but receiving a string.
Has anyone found a reliable way to pass a dynamic number (like estimate in days) into plusBusinessDays()?
Note: I still need to skip the weekend
In Jira Cloud, Server, and Data Center automation, a Created Variable is always text / string, and must be converted for use as other types. And...
You are using Jira Data Center, and thus for automation rules:
Okay, back to your question: please try this expression with your variable, assuming it is an integer:
{{#now}}func=plusBusinessDays({{workdaysToAdd}}){{/}}
Kind regards,
Bill
Hi @Bill Sheboy
I tried
{{#now}}func=plusBusinessDays({{workdaysToAdd}}){{/}}
2025-08-15T17:14:39.1+0000
When i tried:
{{#issue.customfield_17971}}func=plusBusinessDays({{workdaysToAdd}}){{/}}
it return:
func=plusBusinessDays(20)
also tried to define a variable to store 17971:
and call it like this:
{{#StartDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}}
it returns:
func=plusBusinessDays(20)
I will need to add the estimation day to my Target Start (customfield_17971) and assign the result to Target End (customfield_19792)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Within rules, the Target Start and Target End fields are text representing dates. And so they must be converted first with toDate:
{{#issue.customfield_17971.toDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}}
And when setting the field, it needs to be in jiraDate format. So save the above value in a variable, perhaps named varTargetEnd, and then format it:
{{varTargetEnd.toDate.jiraDate}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
wow, it works! Thanks @Bill Sheboy
Let me summary how:
{{#=}}{{issue.timetracking.remainingEstimateSeconds}}/28800{{/}}
{
"fields":
{
"customfield_17972": "{{#issue.customfield_17971.toDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}}"
}
}
Follow-up question:
How to make it works on Advance Roadmap? On Advance Roadmap when I edit the field i will need to review and confirm apply it before I can see the updated Target Date
Are there any way to make it real-time showing the updated Target Date when I change the Estimates (d) ?
Posted it here: https://community.atlassian.com/forums/Jira-questions/Apply-Automation-Rule-on-Advanced-Roadmap-JIRA/qaq-p/3072417#M1137861
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, I do not believe so. Please see Walter's explanation in your other question. Thanks!
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.