Multiple community members have asked the following question recently:
"When I change the end date of a task, how can I have that change automatically update the start and end date of dependent tasks, while also maintaining the original duration of the dependent task?"
Jira Cloud does not do this inherently, but it can be done with limitations using Automation for Jira.
Disclaimers and Caveats:
- This solution does not leverage functionality that is available in the Plans feature that is part of Jira Premium and Enterprise subscription plans.
- This solution does not rely on third party apps.
- This solution does rely on the use of the native Issue Linking feature of Jira where the link type used has different values for Outward Description and Inward Description.
- The chain of dependent tasks can be no more than 10 tasks. This is a service limit imposed on Automation Rules that they cannot recursively call themselves or other rules in quick succession more than 10 times.
- If you set up dependencies between tasks that are in different projects you will need to create a Multiple Project Scoped or Global Scoped rule to be able to edit the issues in all the relevant projects. For more information on rule Scope refer to What are Rule Details? (Scope)
- There are monthly Usage Limits for Rule Executions. Consider how adding this rule to your environment will impact your usage. For information on those limits and how usage is calculated refer to How is my usage calculated?
Consistently Using Block Issue Link Types
For this solution, I have used the out-of-the-box Issue Link Type named “Blocks”, defined as follows:
- Name: Blocks
- Outward Description: blocks
- Inward Description: is blocked by.
You can use a different link type, as long as the Outward Description and Inward Description are different from each other.
This solution relies on consistent usage of the Blocks issue link type. If A-2 depends on issue A-1 being completed before work on A-2 can start, then this rule assumes that the two issues are linked as follows:
A-1 blocks A-2
Conversely:
A-2 is blocked by A-1
If you have multiple tasks that depend one upon another in a chain, they must be linked consistently:
A-1 blocks A-2
A-2 blocks A-3
A-3 blocks A-4
A-4 blocks A-5
Also for this solution, I have used the following Date Picker fields:
Due date: the date the task is expected to finish
Start date: the date the task is expected to begin
Where I use "Start date" and "Due date" you need to substitute the names of the fields that you actually use to indicate the starting date and ending date of your tasks.
A Summary of the Rule:
- Trigger: Field Value Change: Due date is changed
- Condition: Issue Fields Condition: Due date is not empty
- Branch: Related Issues: Linked Issues that are linked by “is blocked by”
- Condition: Issue Fields Condition: linked issue Start date is not empty
- Condition: Issue Fields Condition: linked issue Due date is not empty
- Action: Create a variable to hold the current duration of the linked issue
- Action: Edit the linked issue
- Set the linked issue Start date to the Trigger issue Due date
- Set the linked issue Due date to the new Start date + the linked issue duration
Note that in the Branch component you will want to uncheck this box:
The rule components that need more explanation are the last two; Create Variable and Edit Issue Fields
To get the original duration of the dependent task we get the difference in days between the original Start date and original Due date using smart value function diff() described in Automation smart values - date and time. We store this in a variable for use in the next step of the rule - Create Variable.
Note: You can alternately get the duration in business days by using businessDays instead of days.
In the Edit Issue action, we use smart values to set the Start date and Due date to new values for the dependent task.
The dependent task’s new Due date is its new Start date plus the number of days calculated as its duration. We stored the duration in a variable we created earlier. We can use the plusDays() function to add that variable value to the new Start date to get the new Due date.
We are changing the Start date in this same Edit Issue action. To avoid any collisions in changing data we will reference the trigger issue’s Due date in setting both the new Start date and Due date for this dependent task.
Variables are stored as strings, so we use asNumber to convert that to a number for this calculation.
When the rule execution completes it will have updated the Start date and Due date of the dependent task. Because it updates an issue Due date, that will cause this rule to be triggered again, with the task just updated becoming the triggering issue for the next execution.
For the rule to be able to operate in this recursive manner you must make sure that you check this box on the Rule Details page:
Want some more Jira tips? Check out Our Guide to Import Linked Issues in Jira from CSV. Or if you're looking for more Atlassian content, check out our Expert Answers to Your Atlassian Community Questions.