Hello to Everyone! So I'm basically trying to do automation for a roll up from the custom fields "Target start" and "Target end" when a story or a work change any of this both fields. I would like to reflect on the Epic level the earliest Target start from all the stories, and the latest Target end from all the stories. This automation should be able to update even when we remove stories or add stories to the epic, or just update dates. I followed this pages for reference: * https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-copy-value-from-quot-Target-End-date-quot-to/qaq-p/922787 * https://community.atlassian.com/t5/Jira-discussions/Set-Epic-Start-and-Due-Date-to-earliest-latest-Child-Dates/td-p/2353100#U2473939 The automation that I have built until now looks like this so far: So there is goes my questions: * How I edit in the last step the target end once is a custom field and I believe that I can just do it by json, this was the input that I found but I believe that is not working { "fields": { "customfield_13603": "{{triggerIssue.Target End}}" } } * I believe for Target start the custom field should be another code right? And in the look up value step should be "asc" * To guarantee that we cover any change in the dates of the child issues of the epic (removed, edit or added) should I refacth the data at any point? Thank you all in advance :)

For that scenario, I believe the same rule can be used, with an adjustment...and I am paraphrasing here to only show the changes in italics :^) With this one, I believe you can remove the new condition we just added. * trigger... * conditions to decided if we should proceed... * branch on the {{fromString}} match to update the previous epic* lookup issues... * update the previous epic * condition to check if the {{toString}} is not empty * branch on the {{toString}} match to update the new epic* lookup issues... * update the new epic

Hello @Bill Sheboy ! I changed to the advance compare condition as you said and it works fine now. So yeah you are right the new epic is being update once covers the trigger of updated issue, but once the old epic is not taking any update the trigger is not covering it. Do you have any idea how to force to run the lookup in the old epic? Thank you in advance, Roberto

For the second condition I noted, you want an advanced compare condition and not a JQL condition: * first value: {{#changelog.Epic link}}{{toString}}{{/}} * condition: equals * second value: leave this empty Although your testing surfaces another case to cover: when the epic changes for an issue, both the old and new epic should be updated.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation to Roll up dates for target start and target end

RXAVIER

Hello to Everyone!

So I'm basically trying to do automation for a roll up from the custom fields "Target start" and "Target end" when a story or a work change any of this both fields.

I would like to reflect on the Epic level the earliest Target start from all the stories, and the latest Target end from all the stories. This automation should be able to update even when we remove stories or add stories to the epic, or just update dates.

I followed this pages for reference:

The automation that I have built until now looks like this so far:

So there is goes my questions:

How I edit in the last step the target end once is a custom field and I believe that I can just do it by json, this was the input that I found but I believe that is not working
{
"fields": {
"customfield_13603": "{{triggerIssue.Target End}}"
}
}
I believe for Target start the custom field should be another code right? And in the look up value step should be "asc"
To guarantee that we cover any change in the dates of the child issues of the epic (removed, edit or added) should I refacth the data at any point?

Thank you all in advance

Accepted answers

All comments

Bill Sheboy

Hi @RXAVIER

Before proceeding, I recommend checking if the Target Start and Target End fields are supported by automation rules. I recall earlier community posts that many Advanced Roadmap fields are not supported by rules. You can check this using this how-to article to confirm if the fields are supported for an example issue: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/ If you find the fields, they are supported.

Let's assume the fields are supported...

For your question #1 and #2, you are trying to update the epic with the earliest Target Start and latest Target End, correct? If so, the source for your edits should be the lookup results. Like this, filling in the correct values for the custom field ids:

{
  "fields": {
    "customfield_13603": "{{lookupIssues.Target End.max}}"
  }
}

For Target Start, use the min instead of the max value.

For your question #3, please consider all of the scenarios you want to handle, as you may need separate rules with separate triggers:

target start or target end fields change in a Work issue
target start or target end fields change in an Epic issue (i.e., someone manually overrode the values)
issue created and added to an existing epic
issue removed from an epic
issue deleted (and so removed from an epic)

Kind regards,
Bill

RXAVIER

Thanks you @Bill Sheboy for you answer I think the automation is almost ready but I'm receiving the following error.

I already was reading this thread but I couldn't found the solution, I believe that my instance as date format as defined is there any walk around or way to check this out?

Thanks in advance,
Roberto

Bill Sheboy

This is one of those situations where Atlassian decided to implement non-standard formats for date and date/time fields.

The fix is to force the field's format during the edit in the JSON to match the requested format. In this case, that would be jiraDate. Using my earlier example, we would add this:

{
  "fields": {
    "customfield_13603": "{{lookupIssues.Target End.max.jiraDate}}"
  }
}

You can learn more about date/time smart values for similar situations here: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#--

RXAVIER

Thanks for sharing that @Bill Sheboy didn't knew about it.

Even though I just tried to run it and got the same feedback from the JSON

This is the audit log (bellow is the JSON)

I didn't tried it for Target Start but I believe that the result would be quite the same. If you have any other option it would be really valuable.

Thanks in advance for you attention,
Roberto

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud