Troubleshoot Automation: Email Parent Assignee All Linked Issues Moved to Done at EOD

[Donna Benton]

I am getting the email correctly. I am seeing issues moved to Done. The issue here is, that I am getting ALL done issues, whether or not the Parent (Epic) is assigned to me. This needs to be a targeted report EOD that shows the Parent owner all work that was completed for only their projects.

I appreciate any help here!

[Trudy Claspill · Accepted solution]

Hello @Donna Benton 

Do you have a JQL within the Scheduled trigger? If so, then the steps in the rule are being will be applied to each issue found by the JQL in the trigger, not to the issues found by the Lookup Issues action.

You can use a JQL in the trigger to find all issues that have a status of Done and where a parent issue exists, eliminating the need for the Lookup Issue action  and the Condition step. 

[Donna Benton]

Hi @Trudy Claspill I do have the JQL shown in the automation above. I am not sure how to make the changes you are suggesting. Can you please walk me through it?

[Trudy Claspill]

Can you show us the details of the trigger step?

Can you show us the details of the Send Email step?

I realized that I missed a detail in your original post.

Do I understand that you want to send an email only to the Assignee on the Epic, and have that include a list of the child issues of that Epic that are Done?

[Donna Benton]

Hi Trudy! Sure, no problem, yes, 'Do I understand that you want to send an email only to the Assignee on the Epic, and have that include a list of the child issues of that Epic that are Done?', you understand that correctly.

Trigger:

Lookup

If Block

Email

Thank you for the help!

[Trudy Claspill]

Is this a rule for child issues and Epics in a single project or might the child issues and Epics be in different projects?

Do you want emails sent to

- every Epic assignee each day?

- only to Epic assignees where a child story has newly transitioned to Done since the last time the rule ran

- only the Epic assignees where a child story that has a status of Done has had any sort of update (status change, field change, comment) since the last time the rule was run?

Your rule is not structured correctly to send one email per Epic. The answer to the above has a significant impact on the details of solution I would suggest. The answer could change the JQL in the trigger, which in turn makes a difference how other steps need to be used to ensure only one email is sent per Epic.

[Donna Benton]

Is this a rule for child issues and Epics in a single project or might the child issues and Epics be in different projects?  Single project

Do you want emails sent to

- only to Epic assignees where a child story has newly transitioned to Done since the last time the rule ran YES

[Trudy Claspill]

Thanks for that feedback.

First update the JQL in the trigger to this:

issuetype=Epic

Also uncheck the box that says "only include issues that have changed"

Then in the Lookup Issues action use this JQL

parent={{issue.key}} and status changed to Done after startofday(-7h) and issuetype in standardIssueTypes()

That will collect all the child issues of the Epic that have transitioned to Done since 5 pm yesterday.

Next, delete the Condition that you have in your rule.

Replace it with an Advanced Compare condition as follows:

And lastly change the recipient of the email to {{issue.assignee.emailAddress}}

In summary this rule will check every Epic for child issues that have transitioned to Done since the 5 pm the previous day and send one email to the Epic Assignee listing those issues.

Note if the issues have subsequently changed from Done to another status, they would still be in the email. If you want only the ones that have changed to Done and are still currently in a Done status, then add and status=Done to the JQL in the Lookup Issue action.

Also note that the email will include only the issues that are newly changed to Done. It will not include issues that were changed to Done prior to 5pm yesterday.

[Donna Benton]

Trudy this is not working. I am not even getting an email at all now.

[Donna Benton]

[Trudy Claspill]

What is the JQL in your Trigger?

What does the Audit Log say for the execution of the rule?

[Donna Benton]

JQL in Lookup: parent={{issue.key}} and status changed to Done after startofday(-7h) and issuetype in standardIssueTypes() 

Audit Log: This shows success, but I don't know why it would, no email was sent.

[Trudy Claspill]

Do you have a JQL statement in the Scheduled Trigger? If so, what is it?

It appears that you must have some sort of JQL in the Trigger, because the Audit Log entry is listing a set of issues associated with the Schedule (on the right).

The message in the Audit Log is saying that no issues are being found by the Lookup Issues action.

Take the issues listed in the right side of the Audit Log entry and plug them in to thee JQL in your Lookup Issues Action. Execute that JQL in the View all issues screen to search for matching issues. Do you get any results?

parent=EP-481 and status changed to Done after startofday(-7h) and issuetype in standardIssueTypes() 

If you are not getting any results and you think you should, can you share a screen image of an issue that you think should've been in the results, that has the specified parent Epic and has been changed to a status of "Done" in the past 7 days?

[Donna Benton]

Can we start over? I feel like this has gotten really confusing. Maybe I need to just start from scratch?

[Trudy Claspill]

Sure, let's start over.

"What problem are you trying to solve?"

You want to send a list of issues to a person...

"What are the criteria for the list of issues?"

1. They are children of an Epic
2. They have transitioned to Status=Done since a specified date/time relative to now. For the sake of an example, let us say that the issues have transitioned to done since 5 pm yesterday (local time).

Let us construct a filter that can find those issues.

To find issues that have changed to a particular status when that Status value is "Done" the filter is:

Status CHANGED TO "Done"

Run that filter in the Filters > View all issues screen to confirm that it works and you get a list of issues that have changed to the "Done" Status ever.

To find issues that have changed to a particular status since 5 pm yesterday the filter is:

Status CHANGED TO "Done" AFTER startOfDay(-7h)

"startOfDay()" equates to 12:00 a.m. of the current day. To get to 5 pm yesterday provide the parameter to subtract 7 hours from 12:00 a.m.; -7h

Run that filter and confirm that you get a list of issue that have transitioned to Done since 5 pm yesterday.

If you only want the issues that are still currently in a Done status (exclude issues that changed to Done and then changed again to another status and did not come back to Done) then the filter is:

Status CHANGED TO "Done" AFTER startOfDay(-7h) and Status=Done

Next, you only want issues that might be children of Epics so you don't want Sub-tasks or Epics in that list; you want all issue types that are at the "standard" issue type level. To get that we add a check of the Issue Type to the filter.

Status CHANGED TO "Done" AFTER startOfDay(-7h) and Status=Done and issueType in standardIssueTypes()

Run that filter and confirm that you get results.

And, lastly, you want only those issues that are children of Epics, so we add a criteria to check if the issue is a child of an Epic. An issues parent Epic is recorded in the Parent field, so we check that field is not empty.

Status CHANGED TO "Done" AFTER startOfDay(-7h) and Status=Done and issueType in standardIssueTypes() and Parent is not empty

Run that filter and confirm that you get results.

And, if you want this information for only issues in a particular project, then add the Project criteria.

Status CHANGED TO "Done" AFTER startOfDay(-7h) and Status=Done and issueType in standardIssueTypes() and Parent is not empty and Project=X

Run that filter and confirm that you get results.

So, at this point we have confirmed that there actually are issues to report in your list of issues - there are some issues in Project X that are children of Epics where these issues have transitioned to Done since 5 pm yesterday and these issues are currently in a Done status.

Next step: You want to narrow down that list to the issues from a particular Epic, because you want to send the list to the Assignee of the Epic.

Looking at the results of the last filter above, pick out one issue and get the issue key for its parent Epic. Then modify the filter to get the qualifying issues from that one Epic by changing Parent is not empty to Parent = <issue key of Epic>

 (In my example the project is "TS" and the Epic key is "TS-7".)

Status CHANGED TO "Done" AFTER startOfDay(-7h) and Status=Done and issueType in standardIssueTypes() and Parent=TS-7 is not empty and Project=TS

Run that filter and confirm that you get results.

Now, let's build the rule to get that information and send the list.

(1) You want this rule to run every day at 5 pm, so start with a Scheduled trigger.

(2) We want to confirm that this rule will work, so we will add a JQL to the trigger to select the Epic we identified above that is known to have a child issue that matches the criteria.

Also, we want to email the list to the Assignee of the Epic, so let us make sure that there actually is an assignee on that Epic.

(3) We want to get this information for this Epic even if the Epic has not changed since the last time we ran the rule, so we need to un-check the "Only include..." box.

With a Schedule trigger, the actions in the rule will be run for each issue retrieved by the JQL in the trigger. To reference that issue in the actions you can use the smart value {{issue}}.

Next, for this Epic we want to get the list of qualifying issues. So we add a Lookup Issues action with the filter that we built up previously. But rather than explicitly specifying the Epic in that filter, we are going to get the Epic key from the rule trigger.

Now we want to confirm that we actually got some issues from that Lookup Issues action, so let us add a condition to check the size of that list.

And, finally, let us add the action to send the email.

Referencing this documentation for Lookup Issues Action, you can see how to print out information for each issue in the Lookup Issues results list. To send the email to the Assignee of the Epic, use the smart value {{issue.Assignee.emailAddress}}

I also added a couple of Log actions to print information to the rule execution log:

(1) the Epic issue key and the Epic assignee

(2) the count of issues returned by the Lookup Issues action

I publish the rule and click Run Rule to test it. This is the output in the rule execution audit log.

Test your rule similarly to confirm you get the expected results.

Then, to run the rule for all Epics in the project specified in the rule scope, change the JQL in the trigger.

From: issue=TS-7 and Assignee is not empty

To: issueType=Epic and Assignee is not empty

For me, this is what the rule execution audit log looks like when there is more than one Epic found by the JQL in the Trigger.

On the right it shows the issues found by the trigger under Associated items: Scheduled and the issues found by the Lookup Issues actions under Lookup Issues

I hope you find that walk through helpful.

[Donna Benton]

Thank you, Judy.