Auto populate start date (minimum) and due date (maximum) of linked issues ,for parent Hierarchy

[sharath krishna]

Hi all , 

I want  to automate  start date and due date from linked issues to epic hierarchy

•  story 1 has start date Jan 1st' 22 & Due date Jan 31st' 22                                
• story 1 has start date Feb. 1st '22 & Due date Feb. 28th ' 22
• story 1 has start date  March 1st' 22 & Due date March 31st 22

So in these linked issues the minimum date is Jan 1st'22 and Maximum is March 31st '22

So the Epic hierarchy should automatically update  the minimum date is Jan 1st'22 and Maximum is March 31st '22, Considering child linked story issues 

Kindly help with automation rules

[Bill Sheboy · Accepted solution]

Hi @sharath krishna -- Welcome to the Atlassian Community!

Are you using Jira Cloud or the Server/Data Center version?  The version you are using will determine how to solve this...

For Jira Cloud, trigger your rule on a change to Start Date or Due Date, then gather the sibling issues with the same epic parent, using JQL and Lookup Issues.  You may then branch to the epic parent to make the edits, using the values: {{lookupIssues.Start date.min}} and {{lookupIssues.Due date.max}}

For Server/Data Center, instead try using the bulk issue features of rules as that version does not have Lookup Issues.

Kind regards,
Bill

[Tomislav Tobijas]

Hi @Bill Sheboy,

Quick question - I've just tested {{issues}} within bulk issue features, but something seems a bit off here.

So, I would like to get the same result as mentioned in the original question and I've constructed the following rule:

Basically, upon change of the End date (on stories), go through all issues with the same epic, and try to get max End date value.
However, I've tested it a bit (with 2 stories within an Epic) and it seems that

{{issues.End date.max}}

only looks at another issue within the JQL results. For example, if I update the value on UOPR-3505, the max result will always be a date from OUPR-3506 (and vice versa).

Am I missing something here or? This was also just for testing purposes, but I'm also not sure even if I get the right value, how could I update Epic End date with right value? There's no Create variable action that I could use either. Maybe to store this 'max' value somewhere (new field or maybe even a webhook)?

[Bill Sheboy]

Hi @Tomislav Tobijas 

First thing: I am using Jira Cloud, not Server/Data Center, and so cannot verify my suggestions for that tool.  

Next, it appears Atlassian is implementing Create Variable for Server/Data Center, and you can follow progress on this suggestion: https://jira.atlassian.com/browse/JIRAAUTOSERVER-22  They are also implementing Lookup Issues for Server/Data Center, and that could also solve this scenario: https://jira.atlassian.com/browse/JIRAAUTOSERVER-53

Back to your question and rule...

I note you have a couple of re-fetches in there.  I have only used this with the Issue Create trigger (as it runs very fast) and when there are changes in a rule.  You have neither of those, so perhaps remove them.  Honestly, I am unclear what re-fetch inside of a bulk-handling branch would mean!

Here is what I wonder is happening...The rules engine appears to be built to prevent collisions and looping errors.  And so JQL branches automagically exclude the trigger issue to prevent problems.

A work-around could be divide and conquer, with two rules:

1. One rule detects an End Date change in a story with an Epic parent, and then branch to the Epic and make a change (like a specific comment) to trigger rule #2
2. Another rule has "Allow Rule Trigger" enabled in the details, and is triggered on a comment.  Now a branch to the child issues should include all others when you look for the maximum End Date.

Kind regards,
Bill

[Tomislav Tobijas]

Yeah, I'm already on the watch list for those suggestions, but cheers for sharing the links! I'm also using cloud automation way more than server so I came here in the hope to find some help 😄

And so JQL branches automagically exclude the trigger issue to prevent problems.

Lol, lovely 😅 I never knew this was the case... I've just tested it and you're right there. You cannot even 'force' the branch to include a trigger issue (I've tried adding OR key = {{triggerIssue.key}}, but no luck there).

Anyway, I've modified your suggestion a bit. Instead of placing a comment on an Epic, I've just used a webhook from the trigger story and then created another automation rule to run on the issue Epic. Nothing fancy, but this would remove unnecessary information/comments on Epic plus notification spam.

So, now getting the right results from

{{issues.End Date.max}}

but how can I get/write down this value to the parent issue as I'm currently in the branch that only looks at child issues?

Btw, thanks for the help and fast reply!

[Bill Sheboy]

I like the webhook technique for this one, although that may not help enough.  My mistake on the two rules advice!

Let's back up and try this:

Back to the one-rule approach, what if you call the REST API with a JQL search, including an ORDER BY End Date DESC, and grab the first record's date in the web response?  That should be usable as a value to edit the epic:

• trigger: end date changes
• condition: end date is not empty
• condition: is a story (or task or bug)
• condition: has a parent
• action: web request to search issues with JQL, waiting for the response to complete
• branch: to the parent issue
  • action: edit the date with the first record in the response

[Tomislav Tobijas]

For this web request action - what does this mean exactly? The action would be Send web request I guess. And what would be the parameters? I just recently started using webhooks so I'm quite new with this + I'm not working that much with REST API.

I think I get what's the idea here, but just would be grateful if you could provide some detailed instructions here.

Cheers!

[Bill Sheboy]

Yes, the idea is to call the REST API method with JQL to gather the issues, and then parse the response.

Here is a good article on calling the Jira REST API from an automation rule: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

And here is the REST API method to call to use JQL for an issue search: https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/#searching-for-issues-examples

[Tomislav Tobijas]

Hi Bill,

Thanks for the info provided in the previous reply!

As we're talking about the DC instance, we've tried almost everything but there always seems to be an issue/limitation with something regarding this or alternative approaches.

As for REST API & automation, everything stated there in the links works perfectly in the cloud. However, I cannot find a way to go through with authorization (source: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828), while that same method works on the cloud. On DC I we get error 500 as a response from webhook and that one does not provide any explanation whatsoever.

Anyway, thanks for the help here. We'll prob. move forward with using an additional ScriptRunner component for this one, although we wanted to avoid that in the first place.

[Bill Sheboy]

I am using Jira Cloud and so cannot test that for Server/Data Center.  My understanding is the send web request action works the same, although it seems the call is being rejected in your case. 

My next suggestion would be to search the community for Server examples with that error and/or work with your site admin to submit a ticket to Atlassian Support.