I am trying to update the Epic Baseline Dates based on Sprint Dates of the Stories. For example:
I have the Target Start / End dates updating on Stories based what Sprint they are moved to, but I cannot figure out how to update the Parent issue dates.
This is the closest example I can find: Jira automation template library | Atlassian
I hope that makes sense...
Thanks for your help in advance!
First thing, I am using Jira Cloud and not Jira Server, so my suggestions are based on what I know about automation rules, and not specifics for the Server version.
In your current rule, have you considered branching to the parent (after the story is updated) to make the change by comparing the date values currently in the epic, parent?
If that will not work...does your version of Jira Server automation have the Lookup Issues action? If so, you may want to take a look at that, using the min and max functions for a list to find the dates you need.
Kind regards,
Bill
Thanks @Bill Sheboy & @Craig Nodwell for responding - really appreciate it!!!
So based on Jira automation template library | Atlassian, I created the following branch rule:
I exported my Automation Rule, but could not attach the JSON here unfortunately, It's a very long Automation Rule, so attaching Screenshots may be a bit difficult. I do think that the base Automation Rule I am using may be a bit over complicated!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Does that rule work as you expect?
I suspect it does not: inside the branch, the edit issue's JSON is setting the dates based on fields in the {{issue}} and at that point in the rule, {{issue}} refers to the epic. (Context and scope are important in rules, and so where you are determines the value of {{issue}}.)
If your trigger issue is the one with the sprint values, please change the JSON to use {{triggerIssue}} rather than {{issue}} as the source of the fields to copy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Isabella Musial I have to agree with @Bill Sheboy your best course of action here is to create a Branch Rule to handle updating the parent.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy @Craig Nodwell Unfortunately, still perplexed by this issue!
A coworker shared the following Automation with me:
Set Epic Start and Due Date to earliest/latest Chi... (atlassian.com)
@Trudy Claspill responded and offered a solution.
The concept is what I am looking for, however, this is using Start Dates.
I want to update the Baseline start / end based on the earliest/latest child dates. AND hoping that those dates update in Structure.
This is a 2-fer really...
I did create this Automation - but this will only run on new changes. (if it runs at all) I would love to run an update so that I can align all the past dates as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Isabella.
For your version of Jira, do you have the Lookup Issues action for rules? I asked that earlier and perhaps it got lost in ideas.
If you have that action, you could:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy OH I like that!!! I'll try that to see if it can work.
Would I need to remove anything out of that current automation?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy I may be over thinking it - to lookup and compare child issues, I added the lookup from
Set Epic Start and Due Date to earliest/latest Chi... (atlassian.com)
And I apologize, but not sure where to add:
And in the Jira world - how would you define Baseline dates vs Target dates? I am thinking Baseline is the "Actual Start Date", etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your rule has not used the Lookup Issues action, and so the {{lookupIssues}} smart value is empty. *** Did you check if you have the Lookup Issues action available? ***
Regarding using the values, you wanted to edit the Epic to contain the min (or max) dates. And so when you are ready to edit the Epic the values may be used.
I do not believe you need all of those extra conditions; and, they would stop the rule from further processing. Perhaps it would be better to just the Epic's date fields to the min (or max) from the child issues, when needed.
Finally, you ask about "target" versus "baseline" dates. If you have separate fields for those, they could be set in the same way. However, I would expect the "baseline" dates to only be set once; please consider at one point you want to do that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks again for responding so quickly! You rock!!
Within the branch you could use the Lookup Issues action to retrieve all the child issues of that Epic via JQL where the field you monitored in the Trigger (Start Date, or Due Date) is not empty, and order the results by that field so that the first issue listed would have the date you want to copy to the Epic.
i.e.: "Epic Link" = {{issue.key}} and "Start Date" is not empty ORDER by "Start Date" asc
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
At this time...the lookup issues action is only available for the Jira Cloud and Jira Data Center versions of automation. With the changes to the Jira Server lifecycle, it is unlikely that action will be added.
And so, a more complicated work-around is to use the Send Web Request action, calling an issue search with the REST API. That would use the same JQL as you would have used for lookup issues, and then provide a list of issue as before. Please discuss approach with your Jira site admin before proceeding.
If you want to try this approach, here is a how-to article and a reference to the REST API function:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, well that's unfortunate. Guess all that for nothing! Ha! That's OK, I learned much.
I will open a new ask for Structure Baseline. I will tag you, maybe you can help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.