How to create automation for interconnected items on the timeline with dependencies (blockers)?
1 answer
I understand automation well, but I'm less familiar with the timeline function. Recently, I created blocking lines on the project timeline in Jira. I would like the date of the blocked task to automatically adjust when the date of the blocking task is changed. However, these blocks were configured directly on the timeline.
Hello @Hernani Júnior
Creating a dependency between two issues in the Timeline should create an Issue Link between them. If you look at the details of those issue you should see information in the Linked Issues section for each one indicating its relationship with the other. Please confirm that is the case. Example:
In the image you shared I don't see issue keys in the relationship box. In the Plans Timeline it is possible to add issue to the timeline, but the issues don't really exist until you Review the Changes and commit them to the related Projects.
Are the two issues in your image unsaved new issues?
Automation rules cannot be run against issues that are not yet committed/created in the project.
I want that when I change the date of one item, the date of the next one is automatically adjusted. Using the example from the screenshot, if I change the warranty date, the Go-Live date should also be adjusted. Specifically, when I change the target end of the warranty, I want the target start and target end of the Go-Live to be adjusted proportionally, since the Go-Live depends on the end of the warranty.
There is still a critical piece of the puzzle that you have not answered - the directionality of the link between the issues. This is important because it will determine which issue is gets updated.
You have said that Go Live depends on Warranty.
Based on the screen image you presented when you view Warranty you see:
"is blocked by"
-- Go Live
That reads as:
Warranty is blocked by Go Live
Assuming that you continue that pattern, then if there was some issue dependent on Go Live the chain would continue with:
Warranty "is blocked by" Go Live "is blocked by" Some Issue.
The rule will have to find the dependent task. It will do that using the specific text you see where I have used "is blocked by". As the rule tries to walk down the chain of issues, if sometimes that is "is blocked by" and other times it is "blocks" then the rule will not be able to operate correctly.
So, for the remainder of this discussion I'm going to assume that you are chaining the issue as shown above, even though grammatically linking the issues in that way is misleading.
The basic structure of the rule is this:
Trigger: When Due Date changes
Condition: Due Date is not empty
Branch: For Related issues / Linked issues: Link type = "is blocked by"
Condition: Start date is not empty
Condition: Due Date is not empty
Action: Create Variable (to calculate the current duration of the dependent task)
{{issue.Due Date.diff(issue.Start date).days.abs}}
Action: Edit Issue
Start date: {{triggerIssue.Due Date}}
Due Date: {triggerIssue.Start date.plusDays(varDuration.asNumber)}}
On the Rule Details page you have to check this box:
When the rule runs it will update the start data and due date of the dependent task. The change to the due date of the dependent task will cause the rule to be triggered again to look for a dependent task for the one that was just changed.
If there are more than 10 issues in the dependency change the rule will stop running with the 10th issue. That is a limit on the number of times rules can trigger other rules in a continuous chain. There are ways to work around that limit, if necessary.
In my example you need to replace "Start date" and "Due Date" with the names of the fields you actually use for recording the starting date and ending date in your issue.
Can we agree on the meaning of these two statements?
- A blocks B.
This is equivalent to saying "B is blocked by A". - A is blocked by B
This is equivalent to saying "B blocks A".
Statement 1 says that A must be completed before B can start. That is the definition of "blocks"
Statement 2 says that B must be completed before A can start. That is the definition of "is blocked by".
The terminology "blocks" vs. "is blocked by" defines what I am calling the direction of the link. It tells you which issue depends on the other issue.
When you create the link between the issues, you choose the terminology to describe the relationship between the issues.
If you choose "blocks" then you are telling Jira that the issue you are currently viewing (TS-42) must be completed before the issues you are about to enter can be started.
If you choose "is blocked by" then you are telling Jira that the issue you are currently viewing (TS-42) cannot be started until the issues you are about to enter are completed.
Let us say we have these links for TS-42.
This tells us that:
- TS-42 must be completed before TS-46 can be started
- TS-43 must be completed before TS-42 can be started
The chain of issues from what has to be completed first to what can only be completed last is:
TS-43 >>> TS-42 >>> TS-46
Now let us say that you change the ending date for TS-42, the issue we are viewing. Which of the two issues linked to TS-42 should be updated based on that change? You want to automatically update only the issues farther "down" the chain - the issue that can't be started until TS-42 is complete - which is TS-46.
The rule needs to move through the chain of issues in only one "direction" - the direction from the current issue to the next issue that depends on it, and so on.
How does the rule know you want to update TS-46 and not TS-43? If determines that based on the "direction" of the link. It determines that TS-46 is the issue that needs to be updated because TS-42 "blocks" TS-46.
Does that clarify for you what I meant?
I can't think of another way to explain this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.