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.

[Joseph HANI]

Hello @Bill Sheboy , 
Thank you again for this precious information ! I have made so much attempts to make it work correctly using the LOOKUP issues. 
I have divided the start date and due date automation since it was creating a loop very fast. 

It works way better now, but I'm still facing the loop exit ... 
I have tried to create multiple automation, but it is even more problematic as it doubles the edition ... 

Sorry to ask you again, but maybe you have an idea on how I could be able to bypass this loop and make sure that the 11 issue will be updated ? 

Thanks a lot for your help ! Have a nice day ! 

Here is the final automation : 

When value changes for : Start Date 
If Linked issues present Types : blocks 

Add value to audit log : Old date {{fieldChange.from}} 
Add value to the audit log : New date: {{fieldChange.to}}
 
Then create variable create smart variable : variable name : dateDifference 
Smart value* name : {{fieldChange.to.toDate.diff(fieldChange.from.toDate).days}}

Add value to the audit log : Date Difference: {{dateDifference}}

 Lookup issue : Search for issue using jQL : issue in linkedIssues("{{issue.key}}", "blocks") 
Add value to the audit log : List issues found : {{lookupIssues}} 

Create a branch For : JQL 
JQL : issue in linkedIssues("{{issue.key}}", "blocks")

Then Edit issue fields Start date : {{issue.Startdate.plusDays(dateDifference.asNumber).jiraDate}}

[Bill Sheboy]

The 10 loop limit applies when the rule self-triggers due to updates (or triggers other rules).  That is, if this rule changes the Start Date in an issue leads to this triggering  the rule again. 

That 10 loop count is from the service limits, and there is no way to bypass it with self-triggering rules.

The risky workaround I described earlier is only for 2-3 levels of issues and flows like this:

1. From the trigger issue, identify its linked issues from the smart value {{issue.issuelinks}}, filtering as needed (or do that with Lookup Issues and JQL).  Save the list of issues in a Created Variable.
2. Use the above issue list to build a dynamic JQL expression to find their own linked issues, again with JQL and the Lookup Issues action.  Save this new issues list in another variable.
3. Merge the issue lists from #1 and #2 to create a combined, dynamic JQL statement, and branch over that JQL to make the updates.  This has an upper limit of 100 issues, but could encounter the maximum processing time limit and halt running.