Update due date of blocked issues if due date changes

[MiDa]

Hello!

I do have many issues which block other issues. 

If I change the duedate of an issue, I want the start date and due date of every blocked issue to be changed by the same delta.

Example:

Issue1: due date = 10.1.2022 blocks Issue2 (link is set)

Issue2: starte date = 20.1.2022; due date = 14.2.2022

Now if Issue1 due date is changed to 15.1.2022 (delta = 5 days) I want Issue2 start date and due date to change by 5 days too.

My rule looks as follows:

with:

{{issue.duedate.plusDays(fieldChange.to.diff(fieldChange.from).days)}} 

and 

{{issue.startdate.plusDays(fieldChange.to.diff(fieldChange.from).days)}}

Due date and start date, both endup empty.

What is wrong with the calculation?

Thanks for your help!

[Bill Sheboy · Accepted solution]

Hi @MiDa -- Welcome to the Atlassian Community!

First thing: please think about your edge cases to test and decide how to handle them in the rule:

1. empty Due Date to empty value (this is possible for some edits)
2. empty Due Date to non-empty value
3. non-empty Due Date to empty value
4. normal case: non-empty Due Date to non-empty value

Next, I wonder if there is a field typing issues, so perhaps try adding toDate before the diff() calls, such as

{{fieldChange.from.toDate}}

If that doesn't work, try explicitly referencing the changed field data with:

{{changelog.due date.from.toDate}}

Kind regards,
Bill

[MiDa]

Thanks for your Help. Now it Works.

I had to fix two bugs:

I needed to add toDate as you proposed. 

and "issue.startDate" needs to be "issue.start Date" with a space.

which is weard, because "issue.dueDate" is without space.

My Automation now looks like this:

with the formulas:

for duedate:

{{issue.duedate.plusDays (fieldChange.from.toDate.diff(fieldChange.to.toDate).days)}}

for start date:

{{issue.start Date.plusDays(fieldChange.from.toDate.diff(fieldChange.to.toDate).days)}}

[Bill Sheboy]

Well done; I am glad to learn you got this to work!

The smart values are case-sensitive and spacing-sensitive, so when in doubt use the information in this how-to article to confirm the smart values: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Also, I note in your rule that you are editing the same issues within the branch multiple times.  That could cause some problems of data getting "walked over" by later edits.  I recommend changing your branch to:

• branch: on linked issues
  • action: edit the description
  • action: re-fetch  (This will reload the issue data before proceeding, although it will slow down the rule a bit.)
  • condition: due date is not empty
  • condition: start date is not empty
  • action: edit the due date and start date fields with one action (You may select multiple fields for an edit operation)
• ...

Please let your testing decide if you want to do this change.  If your rule works and the description is still present after the date field edits, your rule is okay as-is.

[Frank Liang]

This automation works really well. Is there anyway to only allow working date and not weekend?

Thanks!

[Bill Sheboy]

Hi @Frank Liang -- Welcome to the Atlassian Community!

You can perform the date diff on business days to exclude weekends: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/

However, that will not account for removing any holidays (non-working days) you have defined; only weekends.

Kind regards,
Bill

[Saumya Vaddamani]

I am doing the same thing for my project which has Target start and Target end. When i need to take action i am not able find mu custom field. And did write a JSON. The automation is getting errors. Can you suggest what should i write.

[Bill Sheboy]

Hi @Saumya Vaddamani -- Welcome to the Atlassian Community!

As this is an older thread, I recommend creating a new question and perhaps linking back to this one.  That will ensure more people see it to offer ideas.  Otherwise, only people following this older thread will see it.

When you create you new question, please post an image of your complete automation rule, 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!

Kind regards,
Bill

[Marco Delgrande]

Hello, Thanks for the topic and the answers here above, I could apply them on my subtasks as well, but i've an issue:

i've a sequence of subtasks

sub-task1 blocks sub-tasks2

sub-task2 blocks sub-tasks3

sub-task3 blocks sub-tasks4

with the automation you suggested is working perfectly for the first case (sub-task2 start date & due dates change if sub-task1 change the due date, but for te 3rd and 4th sub-task nothing happens. (which should be the case, because the sub-task2 due date is changing too)

is there a way to adapt the automation to make all the cascade sub-task changing?

thanks in advance for your suggestions

[Bill Sheboy]

Hi @Marco Delgrande 

Your use case is related, and different from the original question, which had a delta-change for all issues.  Yours has relative changes for each sub-task dependency.

When you have a new question, I recommend creating a new question and linked back to the related one.  Otherwise only the people following this older question may see it to offer ideas.

Back to your question...

Without seeing your exact rule details, I hypothesize it is a co-incidence your rule works for any of the sub-tasks.  The reason is that I suspect you have a branch in your rule to walk the issues; branches on more than one issue are executed asynchronously and in parallel.  So there is no predictable order of execution, and there isn't even a guarantee that the branch will complete processing until the final step of the rule!

Two possible work-arounds for your use case are:

• Buy a marketplace addon which can perform this kind of adjustment
• A riskier, divide and conquer approach:
  • Write one rule which detects the first change in a chain of issues, and as its last step have it update the downstream issue with some type of indicator (e.g., special comment, set a custom field, etc.)
  • Write a second rule to detect the above indicator, update that issue and any dependent issue, and again update with the indicator for the dependent issue.   When there no more issues, there is no indicator; this is the stopping condition for chained processing.  This rule will have the option Allow Rule Trigger enabled, so essentially it can trigger the next execution of itself.
  • The riskier part: when there are many rules in this chain, this second rule could lead to a service limits violation due to excessive processing per unit of time.

Of note, I recall a community post about the Atlassian roadmap team experimenting with this cascading adjustment in a dev hackathon, but there was no information of that being released to production.

Kind regards,
Bill