Updating Epic assignee with current sub-task assagnee

[yaro137]

I created a rule that will trigger email reminder after an issue isn't updated for 7 days but when I test it it looks at the assignee name and I'd rather have it checking assignee of current sub-task in process. Not sure if the Epic assignee can automatically be updated with the assignee of the running sub-task or rather try to somehow filter out the subtask assignee. It would also be really good if an email gets sent as to next sub-task assignee as soon as the previous one is marked done. I'm fairly new to jira workflows so possibly this is somehow available right out the box but I just can't see it.

[Darryl Lee · Accepted solution]

So, if I correctly understand the requirements:

• IF parent issue not updated in last 7 days
• AND subtask status = IN PROCESS
• THEN send a notification to... the subtask assignee?

With these assumptions:

• Only one subtask will ever been IN PROCESS at a time.
• If there are more than one subtasks IN PROCESS, then the assignee for each of those will receive a notification.

If that's the case, then I think something like this should work: 

Now, I'm a little concerned that checking the Epic for updates may not be what you want.

Because are you really wanting to know whether any Sub-tasks have been sitting IN PROCESS for > 7 days? It's important to consider that even if somebody updates/closes their sub-task, it will not update the parent Epic. So even if people are hustling working on sub-tasks (all within 7 days), if nobody has changed the Epic in 7 days, a notification will still go out.

So then to simplify things, you could just look for any subtasks that were IN PROCESS and not updated in the last 7 days.

Also, did you want to notify the Epic assignee of the delay? You could do that, by adding {{issue.parent.assignee}} to the recipients.

[Darryl Lee]

That simpler rule would look like this:

[yaro137]

This is really nice. I tested and works as expected although I must admit when I use field like {{issue.key}} in the email body I'm not sure why it specifically selects the subtask key/number (which is what's needed here indeed) and not the Epic number. Also, how do you get the corresponding jql names related to a given field?

[Darryl Lee]

So {{issue.key}} will select the subtask because the Branch rule is processing subtasks, and so that's what the issue.key refers to.

If you also wanted to include the Epic number, you could do:

This issue is a blocker for this Epic: {{issue.parent.key}} 

And if you wanted those issue keys linked:

<a href="{{issue.url}}">{{issue.key}}</a> is currently blocking the following Epic: <a href="{{issue.parent.url}}">{{issue.parent.key}}</a>

[Darryl Lee]

As for figuring out fields for JQL, the easiest way to do that is to open up a Search in another window, where you can toggle between Basic/Advanced, and also take advantage of auto-completion: 

https://confluence.atlassian.com/jirasoftwareserver/advanced-searching-939938733.html

Then when you have the query you want, copy-and-paste that into your rule.

[Matt Doar]

What if you have more than one subtask with different assignees?

[yaro137]

Well that's exactly the case but there is always only one "In Progress". Unless more than one can be in that stage that it would complicate things as then each of the assignees with a sub-task in progress would need to somehow get the notification of their progress delay.