Will Jira automatically change due dates on linked issues?

[lebourg]

I have numerous occasions where I need to change a due date on one task and have all the tasks after move out as well. This is very tedious even with Bulk change.

[Nic Brough -Adaptavist-]

No.  It's the wrong thing to do for most users - a due date belongs to the issue it is on, not other issues.

[lebourg]

However, changing a due date on one issue should be able to push out due dates on linked or child issues. I would think this would be helpful for anyone who is using Jira for hardware projects.

[Nic Brough -Adaptavist-]

No, in most cases, they should not do this. Why should due-date on issue X change just because it happens to be linked to another issue that changes? I know what you're thinking of - project planning where you want *dependencies* to change if dates move. That's fine, but it's a disaster to do it at issue level automatically. If you really need this, please don't try to inflict it on issues. Planning dependencies is a totally different thing. Have a look at the Portfolio addon instead - that does planning without needing to break all your issue data.

[Nic Brough -Adaptavist-]

See the conversation above.

[Syed Arshad Aziz]

I am confused. JIRA is supposed to be able to do Project Management. If I use MS Project for managing a project, I can set it up, so that the start date of one activity is dependent on a previous activity. If that is not possible in JIRA / JIRA Agile, then not sure, how it can be called a Project Management tool and not have a way to do such basic things that other PM tools provide out of the box. If there is any blog articles that explain how to setup dependencies to handle such scenarios, please advice

[Nic Brough -Adaptavist-]

Date planning is NOT project management, it's one *tiny* part of it. I'd also point out that a desired due date should NOT move because of dependencies, that breaks the whole point of having a due date - you should be planning on release dates. The really simple scenario here that proves due dates should not be used like that: "The company needs to plan for Christmas". You enter a due date of 25th December. You should not, and can not change the due date. You can plan to miss it completely, but changing it is nonsense. It doesn't matter what your dependencies or resources are, it's still due on the 25th. You need a set of planned dates to be set up and/or use the release dates on versions. In fact, dependency and resource management can be quite a complex field in itself, and JIRA is only part of the toolset you could use. Personally, I never describe JIRA as "Project management" software, because it only covers the "task list" and "issue tracker" part of project management. In some ways, I think Atlassian picked the wrong phrase for describing JIRA in that sense. Jira handles that planning well in an Agile sense, but not the overall picture (for that, I'd reach for Portfolio nowadays).

[Luke Dodd]

Hi - I got this working using Automation for Jira.

I am choosing to use "End Date", not "due date". Just change "end date" to "Due date" in the strings below.

Create a simple test project first, with a few tickets created and set the end/due dates.

First create a rule like:

• Field value change for “End date”
• Issue condition to ensure it is only an issue you care about
• Log Action with the following:

{{fieldChange.fromString.toDate}} | {{fieldChange.toString.toDate}} |  {{fieldChange.toString.toDate.diff(fieldChange.fromString.toDate).days}}

Once you are sure that is producing the right value in the logs, complete the rest of the rule:

• Field value change for “End date”
• Issue condition to be sure it is only an issue you care about
• Branch on jql:

project = {{issue.project.key}} and "End Date" >= "{{fieldChange.fromString.toDate.jqlDate}}"

• Edit issue, select the End Date field and use the following:

{{issue.End Date.plusDays(fieldChange.toString.toDate.diff(fieldChange.fromString.toDate).days)}}

This will move all Tasks with an end date that is the same or greater than the trigger task end date by the same amount of days as the trigger task moves. It works to push dates backwards AND forwards.

As Nic Suggests above, this is not necessarily best practice for Project Management, so please do use baselines and report on movement of dates. At the start of the project, I use "Baseline End Dates" and never touch them. I then created a filter and subscribed to it, so that there is regular reporting of tasks that exceed the baseline dates.

If you want "Belt & Braces" then use email automations, or the twilio plug-in to send you an SMS every time that the baseline is changed ;)

This is a good use case for a high volume of project dates that needs to be moved regularly (and you could not afford to hire someone to maintain the dates 24/7!).

(Credit to Nick at CodeBarrel for the assist)

[Emma Spillane]

Hi Luke, thanks for the details above. I'm v new to Jira/Automation. This may be a silly question but what do you mean when you refer to the below. i.e. what component do I choose when setting up the rule?

• Issue condition to ensure it is only an issue you care about