How can I pre-populate the start and end date of a subtask?

[Andrea Unwin]

I want to be able to enter the start date for Story A, have that start date become the start date for Subtask A within Story A. Then the end date for Subtask A will automatically be set as one month after the state date for Subtask A. Then the end date for Subtask A will automatically become the start date for subtask B. Then the start date for Subtask B will set the end date for Subtask B one month later. Essentially I want to be able to set one start date  for Story A and see a predicted timeline for the rest of the subtsks in Story A. 

Then, if I change any of the start or end dates within the chain of subtasks in that Story A, the following subtasks should still automatically shift based on that date change. 

How can I do this?

[Trudy Claspill]

Hello @Andrea Unwin 

You can do that through Automation Rules. Are you familiar with Automation Rules?

https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

The first thing that you have to figure out is how will Jira be able to look at the subtasks and determine their order. Will you using generic issue linking to link them together so that the first subtask blocks the second subtask which blocks the third subtask, and so on? Jira Automation will have to be able to programmatically determine which subtask is the first one in order to update it and then figure out which subtask is the second one and so on.

I wrote a community article on how to update the start date of a dependent task based on the end date of its predecessor being updated. You can find that article here:

Updating dependent task's dates when predecessor task date changes 

This does not cover the scenario of needing to automatically initialize the dates on the first subtask, nor using that to iterate through the other subtasks and initialize their dates. The initialization process would need to be a separate automation rule.

For the initialization scenario, which you are triggering by setting a date on the parent issue, you will need to have a method for Jira Automation to programmatically determine:

- which of the child subtasks is the "first" subtask"

- what the duration of each subtask should be (if it is not a fixed value that applies to all subtasks)

My article also does not cover the scenario where the start date is being manually changed, and you want to automatically update the end date of the same subtask. My article specifically covers just the scenario where the preceding subtask's end date has changed, causing a change to the successor subtask's start and end dates that also maintain the original duration of the successor subtask.

I would suggest a separate rule to handle the scenario where a start date is changed, with the rule modifying just the end date of the same task. For that rule you would need to make sure that the option on the Rule Details page to allow the rule to be triggered by other rules was NOT enabled. When this rule finishes and updates the end date of its own subtask, that would trigger the rule I wrote about in my article.

[Andrea Unwin]

Would you be able to make a draft of what the automation rule would look like? I have already spent hours trying to create on similar to this and would love any help you are able to lend.

[Trudy Claspill]

Which rule are you talking about? In my reply I've mentioned 3 different rules:

1. Initialize the dates on subtasks, based on the start date being set on the parent issue.

2. Update the end date of a subtask based on a manual change to its start date, maintaining the original duration of that subtask.

3. Update the start and end dates of successor subtasks, maintaining their original durations, based on the end date of a predecessor subtask being updated. This is the rule described in my article, for which I provided a link.

#1 depends on 

- how you identify the first subtask under an issue

- how you identify the subtask sequence (i.e. through issue linking or some other method)

I can't hypothesize on a rule for that scenario without you providing that information.

#2 is fairly straight forward, but has one step that is more complex:

Trigger: Field value changed: <your start date field>

Condition: <your start date field> is not empty

Condition: <your end date field> is not empty

Action: Create Variable
This is the more complex step.
Here you have to calculate the change to apply to the end date. You can use either of two calculations
- The original duration of the task based on the start date before it was changed and the end date.
- Or the difference between the original start date and the new start date. 

Action: Edit Issue
Update <your end date field value> using the value stored in the Variable.
The exact update syntax depends on which calculation you use for your Variable.

[Aaron Pavez _ServiceRocket_]

Hi @Andrea Unwin 

> I want to be able to enter the start date for Story A, have that start date become the start date for Subtask A within Story A. 

It can be done like this

edit start date

>  Then the end date for Subtask A will automatically be set as one month after the state date for Subtask A. 

then re-fetch and then edit due date.

- re-fetch is needed because we need to reload the date (Start date) being used in the same automation.

- the custom field value its the start date ID. check that ID on your instance.

you will see this:

that is the easy part

> Then the end date for Subtask A will automatically become the start date for subtask B

this is a bit more difficult. ill check this tomorrow.

regards