Automation : Update date value based on a variable

[Joseph HANI]

Hello everyone ! 

I'm trying to create, where if I change the start date of an issue for the issue linked, it should change the start date with the same number of days than the parent link. 

I figured out a way to create a variable where it calculates the number of days that has change (minus or plus). 

Everything is showing correctly in the audit log, if I change the start date for 3 days if show "3", I also have a "SUCCESS" showing, but the start date on the linked issues is being emptied ... 

Here is the automation : 

And here is the value inside my edit field start date (customfield_id = start date)

{{issue.customfield_10083.plusDays(dateDifference).jiraDate}}

I'm not sure where it blocks and why the field is being emptied ... If anyone has an idea on this ! 

Thank you ! 

Have a nice day ! 

[Bill Sheboy · Accepted solution]

Hi @Joseph HANI 

First, I recommend reviewing this article from @Trudy Claspill on this type of scenario:

https://community.atlassian.com/t5/Jira-articles/Updating-dependent-task-s-dates-when-predecessor-task-date/ba-p/2816977

For the rule you show, a Created Variable is passed as a parameter to the plusDays() function.  That parameter should be a number but variables are always text.  Please try adding asNumber to convert the value:

{{issue.customfield_10083.plusDays(dateDifference.asNumber).jiraDate}}

Kind regards,
Bill

[Joseph HANI]

Hello @Bill Sheboy 

Thank you very much for your answer ! You are always a great help ! So bad this articles does not come up in my google search (sob) 

You were right !! Using the "as number" made it work like a charm ! 

One last question if it's okay, it is working on the direct link issue, but it does not work in cascading issue. Do you think it is a good idea to create 3 automation to change on 3 level of linked or there is a better way to do ? 

Thank you ! 

[Bill Sheboy]

Short answer: maybe.  Which is why I suggested reading Trudy's article and comments to it.  If you have 3 issue type levels, 3 rules might be better for this scenario.

Beware: longer explanation ahead :^)

Scenarios like this are essentially trying to re-implement features of purpose-built, project management tools using automation rules, such as cascaded, date shifting.  Although rules can be attempted to make this generic, they are risky.

For example, let's assume you have two levels of linked issues:

Issue A, is linked to:
  Issue B
  Issue C
  Issue D

And so the rule has one execution / loop, and everything is okay-ish. (Assuming no errors, outages, etc.)

What about three levels of linked issues:

Issue A, is linked to...
  Issue B, is linked to...
     Issue B.1
     Issue B.2
  Issue C
  Issue D, is linked to...
     Issue D.1
     Issue D.2
     Issue D.3

There is an option in the details at the top of rules rules to:

Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.

If that is enabled, when Issue B is updated, it will trigger the rule a second time to update its linked issues (B.1 and B.2).  And again for B.1 and B.2.  Same for issues C, D, D.1, D.2, and D.3.  Those additional rule runs would count as "8 loop executions" in terms of the automation service limits (The first one does not count, I think): https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Up to 10 loops are permitted as this "controls how many times a rule can trigger itself (or other rules) in quick succession before the execution is stopped and marked as a LOOP."

There is no documentation on what "quick succession" means, and it certainly happens during the time to update about 10 issues.  Plus, it only takes one "oops" where issues are cross-linked and everything halts (e.g. A -> B -> C -> A)

Thus if you are certain there are fewer than 10 issues, you can try enabling the option.

Now, the work around (for up to 100 issues) for your scenario...

Let's assume you have 3 levels again.  Using the Lookup Issues action repeatedly, the {{issuelinks}} smart value, and list iterators, it is possible to build a dynamic JQL statement to cover all of the issues beyond the trigger.  Then use a branch on JQL to update them all at one time, with no rule recursion / looping.