Listener to notify when issues are created in watched epic

How would I create a ScriptRunner listener that notifies users who are watching the parent epic when issues are being created in that epic. It sounds like something obvious that JIRA should be doing by default but it doesn't.

Ideally the notification should be the default JIRA "issue created" event for the child issue, even if the notification scheme for the project where the issue is created would not normally notify the user.

If that's not possible, a custom email would also work. The custom email should contain title and link for the parent epic and for the just created issue as well as the user who created it.

A third option would be for the listener to automatically make every user who's watching the parent epic, also a watcher for the issues created in that epic. This may be undesirable though compared to the previous two actions which let users manually pick the issues they want to watch.

3 answers

Hi, I did such things (although not exactly the same as your case).

I would

  • create a scriptrunner listener for an "issue created" event, and in the listener:
  • check if there is an "Epic-Story Link" type link, if yes:
  • get the Epic linked to the issue
  • get the watchers of the Epic
  • send a mail to these watchers


Thank you Marc for your answer, it's a good step in the right direction.

However, we have no idea how to translate that into Groovy scripting and the examples provided by Adaptavist don't help much with this specific question.

Since ScriptRunner is commercial now I think their support should be able to help with specific code. The thing is I'm not even sure if this is the place to ask for official support, if anyone at Adaptavist is monitoring this. I can't seem to find a way to get my question in the right topic which seems to be here:

Since ScriptRunner is commercial now I think their support should be able to help with specific code

We help a lot with coding questions. What the support agreement doesn't cover is us writing users' projects from scratch, otherwise it would never end. We do have a large number of fine consultants that can do that though.

I had a look at this, but I don't see any satisfactory solution. If the issue epic link is set at the time of the issue being created, fine. But it's more common to drag and drop them in to the epic in the board. This is not possible to catch - you can blame for that.

Given that, any solution is only going to work "sometimes", so seems a bit pointless.

Thanks for answering, Jamie. I agree that writing all your customers code is unsustainable but maybe a lot more examples can be added (over time) to the site whenever you guys think the questions you answer are generic enough to be useful for others. I did look at the examples for a couple of days before deciding there's not enough there to help me with this request especially for someone with no Groovy experience. It would help a lot with expanding the user base for your add-on. Right now most use cases are too cryptic and require paying a consultant like you said. The examples did help me with other projects though.

Back to the point, we are exclusively adding issues to epics from inside the epic by clicking the + button in the "Issues in epic" section, so the Epic Link is always set when creating these issues. We never drag and drop in the Agile boards.

Can you give me a code sample for that scenario? I imagine it would be useful as an example for the documentation too as there's barely anything about the Epic link type right now.

Thanks in advance.

Hi Daniel,

I've been speaking with Jamie Echlin and Nic Brough internally about your issue this morning, and I believe we've got a route through this issue.  I'm going to code this up on my local development instance this afternoon, but please bear in mind that it's quite complex, so may take some time!

Just to give you a bit of insight into the issues with this particular query:

  1. As Jamie E pointed out above, JIRA does not fire any events on Issue Linkage.  After some testing, we've confirmed that's also the case for Epic Links (even though there is also an Epic Link field).  There is a route around this which we will be utilising, but it is quite complex, and will require a small amount of reconfiguration at your end (an additional, hidden, custom field).
  2. In an ideal world, we would like to use the Notification Scheme to create the emails, which would allow us to trivially use the built-in velocity templates for the email content.  Unfortunately, Notification Schemes are dependent on Events being fired, and the content of the issue attached to the event is used to drive the email.  In this particular case, we need both the content of the Story, and the content of the Epic (to drive the To: part of the email).  As such, we'll need to generate our own custom email in code, which adds to the complexity.

With these primary issues in mind, we're going to use a Service similar to the Escalation Service (as per to search for Stories that have been updated recently to check whether they have a new Epic Link.  We'll then update the hidden field mentioned earlier on the Story with the Epic value, and send the appropriate message.  Obviously if the hidden field already has the correct value, we won't send the email.

For future script development, I would strongly recommend setting up a Dev environment with an appropriate IDE, as per the documentation here: - it makes the development of scripts infinitely easier by giving you direct autocomplete access to the JIRA Java API.

Anyway, I will update here later today with an update.

Jamie Sawyer

Thank you Jamie S for looking into this. That does sound like a lot of work for something that can be summarized in one line!

How about the workflow Marc suggested below. Is that more straightforward/easier to implement? Any downsides to that approach?

Hey Daniel,

The recommendation from Marc below would work for your particular use-case, although as Jamie E suggested above, it would cause issues in any cases where you want to attach a story to an issue after each have been created (through the drag+drop interface), or moving stories from one Epic to another.  The method we're implementing would end up being pretty similar to Marc's suggestion - excluding the method for picking up the issue (the listener in Marc's suggestion and the Service in mine), we'd then be following the same steps - check the link exists, grab the watchers on the related epic, and send the mail - in both cases you'd still have the problems in generating the email.

Long story short, although we're handling a broader remit of cases than you require, the effort to implement would be similar, and this code is more generic.

Jamie Sawyer

Hey Jamie, quick check in, any progress or new insights into this?

Hi Daniel,

I know this is a little bit late, but I wanted to add some example code as we did something similar.  We only add watchers if the user is watching the epic, we don't send notifications.  That being said, see my code below for an example.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.user.ApplicationUser

def watcherManager = ComponentAccessor.getWatcherManager()
def issueManager = ComponentAccessor.getIssueManager()
def customFieldManager = ComponentAccessor.getCustomFieldManager()

//defines the current issue and gets an object that represents the epic link
def currentIssue = issueManager.getIssueObject(
def epicLinkObject = customFieldManager.getCustomFieldObjectByName("Epic Link")

//gets the key of the epic, which is used to get the actual issue object
def epicID = currentIssue.getCustomFieldValue(epicLinkObject)
def epicIssue = issueManager.getIssueObject(epicID.toString())

if(epicIssue != null) {
//gets the list of watchers on the epic
def watcherList = watcherManager.getWatchers(epicIssue, Locale.ENGLISH)

Defines a list of issue types to perform this action on
You can get the ID be going to the edit page for the issue type and viewing the URL
def issueTypeList = ["<Issue Type ID>"]

issueTypeList.each { id ->
if (currentIssue.getIssueTypeId() == id)
//sets the current users as watchers
watcherList.each { ApplicationUser user ->
watcherManager.startWatching(user, currentIssue)
// you could call sendEmail here on each watcher, you just need to get their email addresses
log.warn("No valid epic for issue "+currentIssue.getKey())

 Here is an example method for sending an email.  As you can see, you just need to pass strings with the email address, subject, and body.

//method for sending an email
def sendEmail(String emailAddr, String subject, String body) {
SMTPMailServer mailServer = ComponentAccessor.getMailServerManager().getDefaultSMTPMailServer()

if (mailServer) {
Email email = new Email(emailAddr);
} else {
log.warn("Unable to send mail")

 I know this approach isn't perfect but it might guide you in the right direction.  Apologies if this came too late, I just saw it when searching for something else and wanted to contribute.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 13, 2019 in Marketplace Apps

Marketplace Spotlight: Marketing apps for Confluence to keep your teams working on the same page


236 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you