Syncing due date delays with start and due dates of dependencies (blocked)

[Ashley Griffin]

When an issue that blocks another issue is delayed, I would like the dependent issue to also sync with this delay. E.g. If increase the due date of one issue by 2 weeks this triggers the due date AND start date for blocked issues to increase by 2 weeks.

I have been trying to create an automation for this, but it seems my smart values for start date are not functioning. However the due date smart values seem to function as desired.

I am using the following set up:

Trigger: When value changes for "Due date"

For Each: linked issue (blocks)

Action: Then edit issue field "due date" to 

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

and "start date" to 

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

As described the due date functions corrects but the start date is removed altogether and left blank.

Any advice?

[Trudy Claspill · Accepted solution]

Hello @Ashley Griffin 

Welcome to the Atlassian community.

I wrote an article on the topic of updating dependent task dates. Let me know if you find it helpful.

Updating dependent task's dates when predecessor task date changes 

[Ashley Griffin]

Thank you for the speedy response Trudy. The article was very interesting however I do not believe it solves my problem. 

Your article describes a scenario where A-1 blocks A-2 and the start date of A-2 is always equal to the due date of A-1. 

In the scenarios I am working with the A-2 start date can differ from the due date of A-1. Therefore I am looking to increase the start date of A-2 based on {{fieldChange.from.toDate.diff(issue.startDate).days.abs}}. 

However, when I implement any such rule I am finding that the start date is removed altogether. 

[Trudy Claspill]

Hi Ashley,

I can see a few potential problems with your automation rule as you've shown it.

1. In the smart values that you are using to set the fields you are attempting to reference the very same fields but you are not explicitly telling the rule which issue's fields you are trying to reference. Each of those smart values need to include a "pointer" to the issue being referenced. Each one should start with 

{{issue.yourfieldname....

2. While dueDate can work to reference the native, system provided "Due date" field, for other fields you need to ensure you are specifying either the field id in the formate customfield_###### or using the exactly correct, case sensitive and space sensitive name of the field. Does your start date field appear on your screens as startDate? If it does not then you need to correct what you are using in the smart value to match the field name as it appears in the screen.

I also recommend using the Log action to print into the rule audit log any smart values you are trying to use to confirm your references and manipulations are correct before you execute actions to change the values. For example you could use a Log action (before the Edit action) to print {{startDate}} . That would help you confirm that you starting point for changing the value of your start date field is actually a valid reference and gives you the correct value.

[Ashley Griffin]

Thanks Trudy, your first point did not make any difference but it looks to be good practice so I will implement from now on. 

Your second point did solve the problem! Which is strange as the dueDate field was functioning correctly but changing the format of startDate to Start date as it appears on screen worked. 

One caveat to this automation is that from timeline view if I drag and drop the gantt bar all child issues move in a similar fashion (nice feature!). However if any of the child issues block another and their due date changes due to epic timeline shift then the automation will trigger and amplify this due date shift of blocked issues. Can you think of a way around this other than turning the automation on and off when I intend to shift an entire epic timeline?  

[Trudy Claspill]

Your second point did solve the problem! Which is strange as the dueDate field was functioning correctly but changing the format of startDate to Start date as it appears on screen worked. 

Due date is a system field provided by Jira. They have additional support for it. Start date is not a system field. From Jira's perspective that is just some random custom field so you need to properly identify it to make the code work.

I can't think of any alternatives to turning the automation on/off for the scenario where you are shifting the parent Epic timeline.

[Ashley Griffin]

Thanks again for your help on this topic, much appreciated.