Upcoming backend changes to Automation platform

[#1]

Hi Community!

We're reaching out to provide details about some upcoming backend upgrades on the Automation platform. Just a heads-up that this will get a bit technical - read on if you’re interested!

What are we doing?

On June 17, 2024, we will upgrade our software stack to the latest version of Java to improve performance and security. The latest Java version includes an upgrade of the Unicode specification from Unicode 10 to Unicode 15.1.0, which supports more characters and locales.

What’s changing?

The Unicode upgrade will introduce the following changes to dates and numerical values:

• Timestamps (e.g., 12:00 AM) will now have a narrow, no-break space character between the time and the AM/PM suffix instead of a no-break space character.

• The same is true for numbers that include spaces. For example, for the fr locale, the spaces between the number 123 456 789,123 will be a narrow, no-break space character instead of a no-break space character.

• Date and time combinations that were previously separated by at will now be separated by a comma. For example, January 1, 1970 at 12:00:00 AM UTC will now be shown as January 1, 1970, 12:00:00 AM UTC (please also note that the white space between the time and AM/PM suffix will change to a narrow, non-breaking space character, as explained earlier).

Visually, not much is changing - but this might affect how you’ve configured your rules, especially when it comes to smart values.

What you need to do

For most rules, no changes will be needed. But if you’re using date, time, and numbers in automation rules (e.g., in smart values) and need them to be in a specific format, we recommend you make suitable changes to support the above format changes. We recommend reviewing rules that use the following smart values:

• Timestamp smart values

  • shortDateTime

  • shortTime

  • mediumDateTime

  • mediumTime

  • longDateTime

  • longTime

  • fullDateTime

  • fullTime

• Date and time smart values

  • shortDateTime

  • mediumDateTime

  • longDateTime

  • fullDateTime

Please feel free to reach us with any questions you may have about the upgrade. 

Thanks!

[Doug Levitt]

Hi @Srini Chakravarthy 

This might affect how you’ve configured your rules, especially when it comes to smart values.
...
For most rules, no changes will be needed. But if you’re using date, time, and numbers in automation rules (e.g., in smart values) and need them to be in a specific format, we recommend you make suitable changes to support the above format changes.

I had some questions

1. Does this change impact only those date/time smart values mentioned (in the article) or all of them?
2. I noticed that I use the following in our "code" (where customfield_12345 is a date/time).  How do I determine if our "code" impacted by this change?
   
   1. {{issue.customfield_12345.replaceAll("T", " ")}}}
   2. {{issue.customfield_12345.todate("yyyy-MM-dd HH:mm:ss").convertToTimeZone("PST8PDT")}}
   3. {{issue.customfield_12345.convertToTimeZone(issue.reporter.timeZone).mediumDate}}
   4. {{issue.customfield_12345.convertToTimeZone(issue.reporter.timeZone).mediumTime}}
   5. {{now.plusBusinessDays(1).convertToTimeZone(initiator.timeZone).diff(issue.customfield_12345).businessDays.abs}}
   6. MAX({{now.convertToTimeZone(initiator.timeZone).diff(issue.issue.customfield_12345).businessDays.abs}},1)
   7. {{issue.customfield_12345.mediumDateTime}}
   8. {{issue.customfield_12345.dayOfWeekShortName}}
   9. {{issue.customfield_12345.as("M/d")}}
3. How can we be proactively notified when the change will occur (so we are ready to implement the necessary fixes immediately afterward)?
4. Does Atlassian Support provide free consultation to Enterprise customers (to review our code and provide an impact assessment)?

@Bill Sheboy - I am curious if you have thoughts about this.  Are you concerned?

Thanks,

Doug

[Bill Sheboy]

Hi @Doug Levitt 

I have been watching this thread to observe what others find.  My thoughts are:

There is no information in the article about changes to any automation text functions or math functions / operations to know how they are impacted by the change from no-break space characters to narrow, no-break space characters.  Without testing, it is unclear to me what impact that will have on rule behaviors, before and after the change.

Regarding the changes to date / time formats, customers can probably only respond to this with code inspection, updates, and testing:

• export all rules to JSON, to search and create of list of rules to inspect:
  • search for any of the named date / time formats for possible impacts
  • search for any use of the Send Web Request action or Incoming Webhook trigger in the rules for impacts from date / time information exchange
  • search for any use of formatting date / time values for consumption in conditions, logical filtering, and actions
  • search for any use of formatting date / time values in output, such as in Send Email, Send Teams, Slack, etc. messages
• essentially: code review every single rule in detail to assess impacts and respond accordingly

This change seems a good case for adding a timeframe-specific, warning banner to the top of the documentation page so customers can prepare: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/

Yes, and...when the changes were first announced for the epic field changes, I recall Atlassian team member's community posts indicated when possible, they would automagically update customers' automation rules.  (That clearly was not likely to happen due to rule variations :^)  As the rollout of that change continues to drag on, only now do we see changes in the rule editor to remind people to update rules for field deprecations.  Given that lesson, I respectfully suggest increasing the visibility of changes like this and perhaps giving more specific support for detecting which rules need updates.  (e.g., provide a downloadable report of potentially impacted rules)

Kind regards,
Bill

[Doug Levitt]

essentially: code review every single rule in detail to assess impacts and respond accordingly

Last night, I exported the JSON to figure out which of our > 250 automations are potentially impacted by this change.

Still, it's not clear how I determine if those identified automations are impacted.  How precisely do I determine this.  Or, do I have to wait until Atlassian releases this change (in our instance) and then retest those impacted automations?

But then, how do I know when this change is coming (so I know when to do this testing)?

It seems to me that Atlassian need a versioning mechanism in Automation for Jira, to avoid this.

At least in our instance, we are using Automation for Jira to create "applications" on top of the Jira Framework.  These type of changes (without a versioning mechanism) are quite disruptive. 

[Bill Sheboy]

As for "when", the article notes the date of 17 June 2024.  I recommend reading the update blog weekly and watching for the changes in green font noting "NEW THIS WEEK": https://confluence.atlassian.com/cloud/blog

The article notes some specific date and date / time formats which may be searched for in rules.  Also search for any dates which are text containing " at " which needed conversion to date as that will change to ", ".  Those will need updates after the change starts rolling out.

For the character change to narrow, no-break spaces, there's probably nothing to test until they make the change (or make additional announcements about text function changes).

[Christopher Rampola]

We have an in-house tool the set the AD account expiration that uses the smart value 

• shortDateTime

Since it's adding NNBSP in between time AM/PM - it's breaking our automation to set the expiration of AD accounts

Is there a work around to get rid of NNBSP? Or can we use a different smart value?

[David Lima]

Hi @Christopher Rampola

You can try the format function; below is an example of the workaround:

{{now.format("h:mm a")}}

Using the format function, you can change the NNBSP to NBSP.

[Christopher Rampola]

Hi David Lima,

We're using this smart value - Expire: {{issue.customfield_10230.convertToTimeZone("US/Pacific").shortDateTime}}.

Where should we put it?

[David Lima]

Hi @Christopher Rampola 

You can change the .shortDateTime for .format

{{issue.customfield_10230.convertToTimeZone("US/Pacific").format("M/d/yy h:mm a")}}

You can see other variables in this documentation and create a custom one.

[Christopher Rampola]

Hi David,

That fixes it. Thank you!

Regards,
Chris Rampola