Hello, Again, Community: I am revisiting my previous automation rules for computing elapsed time-in-current-status and I'm trying to identify the errors in my system date-time arithmetic. I have three automation rules: * One rule captures current system date whenever an issue transitions to a different status and updates the issue custom field "Issue_Status_Start_Date"; * One rule runs Tue-Sat @ 0100 and gets current system date and updates the issue custom field "Issue_Status_Elapsed_ChkDate"; * One rule runs Tue-Sat @ 0130 and computes difference between "Issue_Status_Elapsed_ChkDate" and "Issue_Status_Start_Date", in workdays, and updates the issue custom field "Status_Elapsed_WrkDays" Here is the date arithmetic to compute "Status_Elapsed_WrkDays": * Status_Elapsed_WrkDays: 2024-05-03.diff(2024-05-02).wrkdays.abs, When the automation rule executes, it generates a error in the log: * Could not convert the field value to a number. Please ensure the value is a number, math expression or smart-value that can be converted into a number.* Status_Elapsed_WrkDays: 2024-05-03.diff(2024-05-02).wrkdays.abs, Does anyone know the proper date arithmetic for this? Continued "Thanks"! -John Tucci Megabyte Systems, Inc.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Date/Time Arithmetic in Automation Rules

John Tucci

Hello, Again, Community:

I am revisiting my previous automation rules for computing elapsed time-in-current-status and I'm trying to identify the errors in my system date-time arithmetic. I have three automation rules:

One rule captures current system date whenever an issue transitions to a different status and updates the issue custom field "Issue_Status_Start_Date";
One rule runs Tue-Sat @ 0100 and gets current system date and updates the issue custom field "Issue_Status_Elapsed_ChkDate";
One rule runs Tue-Sat @ 0130 and computes difference between "Issue_Status_Elapsed_ChkDate" and "Issue_Status_Start_Date", in workdays, and updates the issue custom field "Status_Elapsed_WrkDays"

Here is the date arithmetic to compute "Status_Elapsed_WrkDays":

Status_Elapsed_WrkDays: 2024-05-03.diff(2024-05-02).wrkdays.abs,

When the automation rule executes, it generates a error in the log:

Could not convert the field value to a number. Please ensure the value is a number, math expression or smart-value that can be converted into a number.
- Status_Elapsed_WrkDays: 2024-05-03.diff(2024-05-02).wrkdays.abs,

Does anyone know the proper date arithmetic for this?

Continued "Thanks"!

-John Tucci
Megabyte Systems, Inc.

Accepted answers

Bill Sheboy

Hi @John Tucci

For a question like this, please post an image of your complete automation rule(s), images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

Have you considered merging your second and third rules?

What are the types of your custom fields: text, date, date / time, etc.? If they are text, please try converting them with toDate prior to performing the diff() operation: https://support.atlassian.com/cloud-automation/docs/examples-of-using-smart-values-with-dates/#Converting-text-to-dates

Kind regards,
Bill

All comments

Bill Sheboy

Hi @John Tucci

Until we see those...

Have you considered merging your second and third rules?

Kind regards,
Bill

John Tucci

Hi, @Bill Sheboy :

My apology for this delayed response...and my sincere "Thanks" for your interest and suggestions, especially the "toDate()" hint, as my date values are text.

Here are the rules:

StatusTimer_Initialize_OnTransition
- Captures the system date when an issue is transitioned and (re)sets the "Elapsed" label (which I use to indicate an issue that has been in its current state for more than 4 workdays):

StatusTimeLogUpdate
- Overnight rule to post/update current system date for Status Check Date and compute # workdays in current status

StatusElapsedFlagger
- Overnight rule (executes 30 minutes after above rule) to set "Elapsed" label on any issue in current status > 4 workdays

Jira_TimeInStatus_AutomationRules_StatusElapsedFlagger.png

I hope this provides enough info to explain what I'm attempting to accomplish, and to provide insight into what I've missed.

Thanks, again.

-John Tucci

Bill Sheboy

Thanks for that information, John.

To summarize, it appears the purpose of your rule set is: detect when an issue has been in the same status for more than 4 working days (i.e., Monday - Friday), in order to add an indictor label.

With text fields to represent the dates, they will need to be converted with toDate before the difference can be done. To eliminate that, why not store them as date fields rather than text?

Your second and third rules could be combined, eliminating any possible timing problems for rule trigger scheduling. I'd recommend performing the calculation and saving the result in a created variable, reducing the need for so many re-fetch issue actions. After the issue updates, the condition from your "StatusElapsedFlagger" rule could be done to set the label.

A couple of follow-up questions:

What do you expect to happen if an issue transitions rapidly across the board? Is the working days count irrelevant to track in that situation?
How is the indicator label removed once it is added?

John Tucci

Hi, Again, @Bill Sheboy :

I'm glad my screenshots made this all clearer. I believe that your pointer to store the date info as date values (instead of text) is the key to making this work! I do also like your suggestion about combining the date update and arithmetic/time-limit detection into a single rule. I will make these changes this week and let you know the results.

For your follow-up questions:

What do you expect to happen if an issue transitions rapidly across the board? Is the working days count irrelevant to track in that situation?
- The working-days count is irrelevant, since the issue won't spend >4 workdays in any given status;
How is the indicator label removed once it is added?
- The idea for this automation is to identify issues that "get stuck"; once we review the "stuck" issue, the developer should be able to move that issue to a new status. That transition to a different status triggers the "initialize rule" that sets the "Status_Start_Date" field to the current time, sets "Status_Elapsped_WrkDays" to 0, and clears the "Elapsed" label.

I believe I've mentioned this upcoming opinion in this forum in prior postings, but, I feel that real-time time-in-status data for each issue should be a basic Jira feature. I believe that there is a long-standing request for this already submitted; I even voted for that request!! It just isn't clear to me how many votes are necessary to move a request into the "being developed" stage.

My sincere "Thanks" to you again for your outstanding help. You are one more element of evidence for the value and character of this Community.

Kind Regards,

-John Tucci

Megabyte Systems, Inc.|
Rocklin, CA

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud