Is there a way to use automation to update the start and end dates of epics to their subtypes, Story

[yhcha]

Is there a way to use automation to automatically update the start and end dates of epics based on their subtypes, Story and Sub-task dates?

I want my stories and sub-tasks to have the earliest and latest start/end dates updated in epic dates.

[Trudy Claspill]

Yes, it is possible to update a parent Epic with the earliest Start Date and the latest End Date from among its child issues.

Within the For Epic branch you would use a Lookup Issues action to look up all the child issues of the Epic that don't have an empty Start Date value.

Then use {{lookupIssues.Start date.min}} as the smart value to get the earliest date from among the result set. Use that smart value to update the Start date of the Epic.

Use another Lookup Issues action to look up all the child issues that don't have an empty End date. 

Then use {{lookupIssues.End date.max}} as the smart value to get the latest date from among the result set. Use that smart value to update the End date of the Epic.

Where I have used the "Add value to log" is where you would use the Edit issue action to update the Start date and End date fields of your Epic. (Also, I used Due date rather than End date).

Note that this picks up the information from only the direct child issues of the Epic. It doesn't consider the subtasks under the issues.

Jira doesn't natively support a method for getting all the subtasks of a dynamically generated list of issues. Without a third party app you can't get both the Epic child issues and their subtasks in one Lookup Issues action.

If you want to consider subtasks I would recommend doing a similar rule to the above to automatically update a parent issue's dates based on its subtasks.

[Bill Sheboy]

Hi @Trudy Claspill 

It is possible to gather up the issues and their subtasks in one query with a rule...but it is often not practical because of the automation processing limits.  For example, the 100 issue limit for Lookup Issues and the execution time limit (depending on what needs to be done).

Let's assume we know there are fewer than 100 total things for issues and subtasks.  We can do this:

• action: lookup issues with JQL to find the issues first
• action: now we create a variable to build JQL to return the issues and their subtasks
  • name: varListJql
  • value:

key IN ( {{#lookupIssues}}{{key}}{{#subtasks}}, {{key}}{{/}}{{^last}}, {{/}}{{/}} )

• action: lookup issues again, using the created variable as the JQL: {{varListJql}}
• ...take some actions

That variable will iterate over the first lookup with a nested iterator over the subtask attribute.

Kind regards,
Bill

UPDATED: I removed the conditional on subtask as that did not consistently work, and appears not to matter as the nested iterator collapses to null when subtasks is empty.

[Trudy Claspill]

I love that I am always learning new things through this community!

Thank you, @Bill Sheboy !

[Bill Sheboy]

Indeed! This question reminded me I had solved this last year, could not find my test rule, and so had to re-create / re-learn the method :^)

[yhcha]

@Trudy Claspill  @Bill Sheboy 답변 너무 감사합니다.
근데 아래와 같은 오류가 발생하고 있는데 이건 어떻게 해결해야 할까요?

An error occurred while running a search by defining a custom value:
Custom Smart Value JQL Search: "("Epic Link"=GKD-30666 and "end date" is not empty) AND (project in (10240))" - Option 'GKD-30666' for field 'Epic Link' does not exist, there are multiple custom fields named 'Epic Link'. Try one of the following search terms: cf[10002], "Epic Link[Dropdown]".

[yhcha]

[Trudy Claspill]

Hello @yhcha 

It appears that your administrators have added a second custom field with the same name as the built-in Epic Link field. The automation rule is not sure which of the two identically named fields you want to use.

It has provided two suggestions for you to use. Based on options provided I believe "Epic Link [Dropdown]" is the second field which your administrators added and "cf[10002]" is the reference to the built-in Epic Link field using its unique numeric identifier.

In your JQL statement where you have used "Epic Link", replace that with "cf[10002]". Let us know if that solves the problem. 

[yhcha]

@Trudy Claspill  hi
Changing the "Epic Link" to "cf[10002]" seems to fix the error, but changing the Story issue date doesn't change the Epic date.

[Trudy Claspill]

Hello @yhcha 

In my example after each Lookup Issues action I used the Log action to just write out the value to the Audit Log. With the language difference I can't tell if you have also used the Log action. To update the Epic you will need to add Edit Issue actions after each Log action to assign the values to the corresponding date fields in the Epic issue.

[yhcha]

[yhcha]

@Trudy Claspill 
I changed the language setting to English
You should see the log on the left side of the image

[Trudy Claspill]

Thank you. 

I see that you have used just the Log action, like I did in my example. The Log action just writes messages into the Audit Log during the rule execution.

However, the first problem that needs to be dealt with is the messages in the log that say that no issues are being found by the Lookup Issues actions.

The branch is being executed, so the trigger issue for the rule does have a parent Epic.

Here are things I suggest that you try to debug this problem.

Within the branch add a Log action and log the smart value:

{{triggerIssue.epic.key}}

That will confirm that smart value is indeed returning the issue key for the parent Epic of the trigger issue. You can compare the value to the issue key information shown on the right in the Audit Log.

Additionally I suggest you try executing the same search through the "View all issues" screen:

"cf[10002]" = fill in the actual Epic issue key here and "Start date" is not empty

Confirm that for the specified Epic there are child issues that have a Start date value. Try the same for search using the "Due Date" field.

You also need to make sure that you are using the correct date fields in your JQL. Do the field names you used in the JQL match the start and due date fields that you actually use in the child issues?