How to Set Due Date in Jira Automation Based on Custom Field with "#d" Format (string)

[Zeroocool]

Problem

I needed to automatically set the Due Date field in Jira Service Management based on a custom text field that contains values like "1d", "5d", etc. The automation kept failing with "Fields ignored: Due date (duedate)" or setting the date to null.

Solution

Action 1: Create Variable

- Variable name: daysToAdd

- Smart value: {{issue.customfield_XXXXX}}

- Replace customfield_XXXXX with your actual field ID

Action 2: Edit Work Item

- Due date: {{now.plusBusinessDays(daysToAdd.asNumber)}}

Create Variable first - Direct field reference in plusBusinessDays() doesn't work

❌ {{now.plusBusinessDays(issue.customfield_XXXXX.asNumber)}} - Direct field reference fails

Use .asNumber - Variables are stored as strings, must convert to number

(In this case 1d converted into '1.0' when testing output in comments)'

Hope this helps others struggling with the same issue!

[Bill Sheboy]

Hi @Zeroocool 

Using an alphanumeric expression as a "number" could lead to unpredictable results.  I recommend parsing it to validate the data and to remove any non-numeric characters.

And...many of the inline date / time functions only take an integer as a parameter, and so using a number in a variable converted with asNumber does not always work as that can produce a floating point value.  (That is, function calls preserve the typing of the left-most number value passed: floating point or integer.)

The two possible workarounds are:

1. as described in AUTO-957 to use the long-format, date / time function (although all of the inline ones are not supported)
2. start with an integer value in the function call, and add the converted variable to it

Kind regards,
Bill

[Zeroocool]

The first goal was to strip chars from the value of the custom_field.

This however failed spectacularly. replace/trim/substringbefore/etc, no matter what I did would render the property null to the automation. No idea why.

I stumbled across directly converting the string (that's stored in a variable) "1d".asnumber to a floating point and it was sufficient for getting it out the door at least.

I wouldn't try to replicate it elsewhere without testing, even conceptually it's an inane way to handle it, but using any of the string methods caused the output to return as null, so I worked within the constraints I found.

It was either that or relying on ambiguous integers alone.

[Bill Sheboy]

To learn more about using created variables as numbers in different contexts, please see this article I wrote on the topic:

https://community.atlassian.com/forums/Automation-articles/Automation-concepts-Using-Created-Variables-as-Numbers/ba-p/2953116

[Zeroocool]

Awesome I'll take a look thanks.

[Tomislav Tobijas]

Hi @Zeroocool ,

There's a know bug related to this: AUTO-957: {{[date].plus[Unit]([number])}} smart value doesn't recognize variables in Automation 
You could check the workaround section and the comments area for some additional insights on the topic. 👀

*btw, I've moved this question to JSM app forum group

Cheers,
Tobi

[Zeroocool]

Actually my issue was that I was unable to generate an integer from a string without the intermediate step of assigning it to a variable. Any attempts would return null. Once it was an integer there was no issue. My issue seems like a step before this one.

[arielei]

Hello @Zeroocool 

Please see here:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/

You can set the variable with surrounding {{#=}} and ending {{/}} - it tells the system to consider this as numbers.

[Zeroocool]

My issue was when I was trying to extract the int from the string "1d", it was resulting in null values, prior to any arithmetic, subsequent variable expansion or coercion. Thus I found a hacky, unintentional, way of producing a floating point. .floor() will come in handy though ;)