Start date change rule not working

[Jo-Lee Bertrand]

I have the following rule configured to run on my project (created by Atlassian AI with some tweaking from me as they picked the wrong field to update). The audit log shows success but the start date value of the parent task is never actually updated.

Any thoughts? 

[Bill Sheboy]

Hi @Jo-Lee Bertrand 

Adding to the suggestions from @Trudy Claspill 

When do you want that field to change as the rule shown might always edit the field?

For example, do you want the parent set to the earliest Start Date for all of its child work items?  Or perhaps the latest date?  Doing this would require using the Lookup Work Items action to gather the children and the list min and max functions to find the correct date.

And the rule shown only updates the parent when one of the child work item's date field changes.  But there are other cases to consider, possibly requiring more rules, such as:

• when a date changes in a child work item, update the parent
• when a work item is created with a parent, update the parent
• when an existing work item without a parent is assigned to a parent, update the parent
• when a work item is deleted, update the previous parent
• when a work item changes to a different parent, update both the previous and new parent
• when someone manually changes the date in a parent, reset it back to the value from the children
• when there is an Atlassian outage impacting rules, my understanding is not all rules with events run to "catch up", and so use a scheduled trigger rule to do so
• etc.

Kind regards,
Bill

[Jo-Lee Bertrand]

Here is my goal - I call it "push-up dates"

1. The task start date is driven by the earliest sub-task start date
2. The epic start date is driven by the earliest task start date
3. The initiative start date is driven by the earliest epic start date

and then same for due date but with the latest due date. My original thought was add roll-up date to the work item but that field is only available in the plans

[Bill Sheboy]

Thanks for that information, and let's look at a simple example for one of the cases:

• trigger: field value changes for Start date
• branch: to parent
  • action: lookup work items, with JQL of
    • parent = {{issue.key}}
  • smart values condition: to confirm a value is found...
    • first value: {{lookupIssues.Start date.min}}
    • condition: does not equal
    • second value: leave as empty
  • action: edit work item to set Start date to 
    • {{lookupIssues.Start date.min.jiraDate}}

If the option below is enabled in the details at the top of the rule, this would update the Start date, in a cascading fashion from the lowest to the highest levels child / parent relationships.

Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.

That rule could be cloned and updated to set the Due Date, with the smart value of duedate.

Again, this handles one case, and not all of the possible ones I noted. 

Particularly this does not handle "tampering" cases if someone changes a date value in the middle of the hierarchy chain. (e.g., Someone changes an Epic's date after it has been updated from its child Tasks.)

[Trudy Claspill]

Hello @Jo-Lee Bertrand 

What are the details of your Edit Work Item action?

What are you trying to accomplish with the rule?

Is any change being made to the Start date field in the issue you want to update? Does the field already have a value before this rule runs?

[Jo-Lee Bertrand]

What I am hoping to accomplish, is when an item has a start date entered or changed, that start date floats up to the items above. so if a sub-task start date changes, I want the task start date to reflect that. I thought I would try the Atlassian AI but it seems wildly off the mark (I've done automation before and this looked far too simplistic but since Atlassian AI created it, I thought I would give it a try). Back to the drawing board.

[Trudy Claspill]

Hello @Jo-Lee Bertrand 

The simple rule structure you have can work. Can you provide answers to the other questions I asked, so that we can explore why it might not be working?

What are the details of your Edit Work Item action?

Is any change being made to the Start date field in the issue you want to update? Does the field already have a value before this rule runs?

Without those details we can't advise on why it is not doing what you intend.

The points made by @Bill Sheboy are also valid. With the current, simple version the parent issue may get updated in scenarios where you would not want it to be updated.

[Jo-Lee Bertrand]

Thanks Trudy - agreed. I need to revisit it. 

[Yogesh Mude]

@Jo-Lee Bertrand Can you add some more conditions like when the field value changes ---also check what is the work type of the triggered work item and see if it has parent or not?

this ensures that if the condition matches then only go ahead or abort.

Also, could you please share the log (source and destination work item) details.

[Jo-Lee Bertrand]

I think I need to completely re-do the automation. Atlassian AI clearly did not work.