Automation rule to schedule monthly, yearly, bi-yearly, quarterly tasks based on time.

[Jason Weddell]

I am working on an automation rule the automatically clones a task based on the time since that task has been cloned.

If a task has a label 'monthly', it clones on the first day of every monthly basis, and the automation works for this.

If a task has a label 'quarterly', it needs to clone on the first day of every three months after it was last cloned.

If a task has a label 'bi-yearly', it needs to clone on the first day of every 6 months after it was last cloned.

If a task has a label 'yearly', it needs to clone on the first day of every year after it was last cloned.

After cloning, the automation will automatically update some fields, edit some fields, and transition the clone to the next state while resetting the 'Actual Start' date of the parent task to '{{now.jiraDate}}' so that the scheduling comparison still works.

The rule I set up was scheduled to run monthly. In it, I had 4 branches - one for each label.

The branches were set up to confirm the label and then confirm if an amount of time had passed since the task's "Actual Date".

For Monthly, this didn't matter, because tasks labeled 'Monthly' would just clone monthly.

For Quarterly, I tried an Advance Compare Condition, but the automation did not consider the comparison of the task's {{issue.actualstart.plusMonths(3)}} - equal to the value {{now.jiraDate}} when I had set the task's "Actual Start" value to November 1, hoping the automation would trigger today, February 1.

The same automation rule failed for Bi-Yearly and Yearly when "Actual Start" was set to 6 months and one year prior, respectively.

I've attached the branch for Quarterly, hoping that if I can get a solution for that, I'll be able to modify the solution to work for the other Label values and Date Comparisons.

Thanks for your attention ahead of time.

[Trudy Claspill]

Hello @Jason Weddell 

In your condition try formatting the output of your new date to match the formatting of {{now.jiraDate}}

{{issue.actualstart.plusMonths(3).jiraDate}}

[Jason Weddell]

That was a fine suggestion. I tested it and the Advanced Compare Condition maintains that a story with the Actual Date "Nov 1, 2023" being 3 months before Today doesn't match the condition.

Image: left side shows rule; right side show automation declaring it isn't a match for the condition.

[Trudy Claspill]

I'm assuming that the field type for Actual Start is Date Picker or Date Time Picker. Is that correct?

Is this being applied to issues in a Company Managed project or a Team Managed project?

Can you show us a portion of the details for an issue, showing the Actual Date field and its value?

Could you please add Log actions to your rule to Log the values as follows? Substitute your field name where I have "Work Started". Then show us the log file results from trying to run the rule.

[Jason Weddell]

Yes, the field type is "Date Time Picker". This is a company managed project. 

Attached is an image of the Actual start field with values "Nov 2, 2022, 4:00pm"

initially, I added your rules to my automation, but no actions were logged in the audit. log.

but THEN I noticed your field "Work Started" had a space in it and my field was "actualstart" when it needed to be "Actual start".

So I changed the value in my Advanced Compare and this happened.

Turns out, Space really was my Final Frontier.

Thanks @Trudy Claspill !!

[Jason Weddell]

Well, I went to run the rule again and it didn't work. Everyone has been so helpful with advice, but this one is still evading me.

[Trudy Claspill]

Please show us the current rule and the Audit Log for when it was executed.

[Jason Weddell]

It took me a while to compile the information. After doing some testing, I think the issue might be rooted in how the 'Actual start' field is configured to set time. here's the rehash:

Goal:

For all issues featuring one of four labels, create a rule that will compare those issues’   Actual start” date with “Now” and if a certain amount of time has passed in that comparison, clone the issue and change that issue’s “Actual start” value to “Now”,
resetting the clock on the comparison. At this time, if the "Actual start" is set to midnight and the date comparison passes, all the cloning works great except in two places.

Problem:

When the rule triggers, it changes the Issue’s “Actual start” value to the day before at  4PM and the Clone’s “Actual start” value to the day before at 4pm. Using a .plusDays1 statement in the JQL doesn't seem to set the dates correctly.

Interesting note:
If Issue “Actual Start” is set the same date at 4pm, the rule doesn’t pass the issue to clone. If Issue “Actual start” is set to 12:00am, the rule passes.

The Rule:

Note that in the rule above, for the Issue 'Actual start', I'm using the extended string to set the date to whatever it was +3 months, whereas on the Clone, I'm simply using 'now.jiraDate' to set that field. In both cases, the date is set to the day before 'Now' at 4pm.

The Audit log:

For the log actions, I'm just trying to make sure the JQL resolves correctly. Seeing Feb 6th as the correct date in the log, I'm confused why the dates populate to the day before in the Issue and its clone.

[Trudy Claspill]

What are you logging in those three Log actions?

I am guessing that the reason you see the field being set to the previous day at 4 pm would have to do with the use of UTC to record date/time values in the DB, and your personal setting for timezone preference.

The database stores dates and time in UTC.

The UI will automatically convert date/time fields to your time zone preferences when you are viewing the data.

When the rule sets the field to Feb. 6, 2023 with no time then 12:00 am gets set as the time. Feb. 6, 2023 12:00 am gets stored in the database.

When you view that in the UI, your timezone preference for Los Angeles converts that to Feb. 5, 2023 at 4 pm.

[Jason Weddell]

That makes great sense. How might I compensate for it? As it stands, I can only run these tests in the morning. In the afternoon, the dates seem to no longer match and the advanced compare finds no issues. If I change the 'Actual start' value a day ahead, the test still finds no issues. 

For the logging actions, a previous comment recommended I add the log actions, so I did. Unfortunately, they only resolve when the test succeeds, so I cannot compare those results to times when the test finds no issues or fails.

[Jason Weddell]

Follow up. by using .jiraDateTime, I'm now able to correctly calculate the "Actual start" and "Actual end" dates for the Issue and its clones. I'm still exploring ways to make the advanced compare succeed no matter when it is tested.

[Bill Sheboy]

Hi @Jason Weddell 

I have observed time zone impacting date/time operations for Jira automation rules...even when all participants are in the same zone.  Perhaps try forcing the values (actualstart and now) to the same zone before incrementing, formatting, and comparing.

Kind regards,
Bill

[Jason Weddell]

Thank you for your kind reply, Bill.

I augmented the statement to set a time zone, and the automation was unable to render a value. Perhaps my smart value statement is overcomplication?

[Bill Sheboy]

It seems to be missing the period between the time zone change and the plusMonths().

[John Funk]

Hi @Jason Weddell  - it needs an underbar - you can follow this format:

{{now.convertToTimeZone("America/New_York").mediumDateTime}}

[Jason Weddell]

My issue has been resolved. the attribute in my advanced compare was mis-written; when it was "actualstart" and should have been "Actual start". See Trudy's response and comment chain on this page for details.

Thank you for your responses and time!