Change parant dates based on child's date (A4J)

[Alex Borges da Silva]

I'm trying to create an automation that once a child item (i.e. subtask) has it's due date, or start date (it does not need to happen in the same automation) changed triggers the automation which:

1. Checks if the date is the earliest or latest date in childs;
2. Checks if this date is earlier or later than the parent's date;
3. Changes the parent's date.

I have made a few researchs ang exchanged some thoughts in this thread Updating start and due date on a parent from its subtasks But still haven't found an answer...

In the image it's what I've tried, based on the afore mentioned post.

It has been returning these errors...

It's in portuguese, but in summary:

The {{lookupIssue.Start date.first}} is returning ')' for some reason, or not working at all

I think that at this moment this is the lock that has been stopping my code from going forward (I could be wrong), going past this I may be able to either finish the code or encounter more questions...

[Bill Sheboy]

Hi @Alex Borges da Silva 

Thanks for the image of your rule, as that may explain this error...

Your branch is referencing a Lookup Issues result but you do not have a Lookup Issues action.  Please add that action before the branch with whatever JQL you need.

Kind regards,
Bill

[Alex Borges da Silva]

@Bill Sheboy 

Once more, thank you for your insights, it makes sense now why the JQL branch is broken.

But I am not finding in any thread how can I create a JQL with all "sibling" issues (all issues under the same parent) without a plugin...

Is there a way to do this query without a plugin? If so, how?

[Bill Sheboy]

That depends upon the issuetypes and parent/child relationships.  For your rule, the trigger issue is a subtask and you want all of the "sibling" subtasks for the same parent.

Thus your starting JQL would be this, substituting in your project name:

project = myProjectName AND parent = {{triggerIssue.parent}}

[Alex Borges da Silva]

@Bill Sheboy 

Right now, I think it is almost complete! There is just an issue with the formating, and I cannot find a reason Why...

I`ve added logs on the end of each JQL branch, as well as declared the variables globaly, but the last sentence says:

"Start date must be in format "yyyy-MM-dd""

But the dates are: 2022-01-18

[Bill Sheboy]

Hi! 

I am guessing that your JQL is trying to use a smart value, correct?  If so, please remember to wrap that in quotation marks to help JQL interpret the value.  For example...depending on what you are matching to:

"Start date[Date]" = "{{lookupIssues.first.Start date}}"

or

"Start date[Date]" = "{{lookupIssues.Start date.min}}"

[Alex Borges da Silva]

@Bill Sheboy 

I've spent a great amount of time trying to fix another issue that popped up, the reason for the Date error is due to the variable exiting the branches with null values...

I saw another post from Atlassian stating that you could create it before the branch and later in a branch assign a value to it, but it is still not working... I`ve used log audits to see the variable value before, within and after the branch,
Ir resulted as follows:
- null
- <the correct date I wanted>
- null again

Below is a snippet of the automation...

Since this is related to a variable problem, would it be better to close this thread with your answer pinned?  

[Bill Sheboy]

I believe the article you note on created variables and branching is this one:

https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Create-variable-New-component/ba-p/1448118

If you read the article and comments carefully, you will note that technique only works when the branch is for one-and-only-one issue, such as branch on parent.  It cannot work for a branch on JQL with multiple issues: each issue in the branch is processed separately and asynchronously, and so automation cannot use the same created variable for each loop pass.  And, there is no guarantee that the branch will finish before the remaining steps in the rule.

This behavior is the original reason I suggested using Lookup Issues: it is one call, no loops, and then allows you to extract the value you want into a created variable.