Differentiate email notifications when an explicit watcher vs a team member?

I'm a team member on a project (actually multiple projects) where all team members get JIRA notifications on changes to all the team's JIRAs.  As such, I get a lot of JIRA notification emails.  I don't think that is a bad thing in and of itself.  I actually want to know when activity is occurring in the JIRA queue.

The problem is I want to be able to differentiate notifications from JIRAs I am explicitly watching vs JIRAs I'm being notified on merely because I'm part of the team.  This would allow me to prioritize reading and responding to such notifications.

My current system of prioritization is email rules that look for explicit mentions of my name in the notification email.  This works to alert me when someone has called me out, such that I can see and reply more quickly than if I was just sifting through all the general notification messages.  However, when I comment on a JIRA, I don't have a good mechanism to be alerted when someone replies.  My email rules cannot differentiate the notification unless the person responding knows (or just happens) to mention my name.

If the notification email could just have a field to indicate I am a watcher, I could easily handle this.  I would just explicitly mark myself a watcher on JIRAs I really care about and I would have my email rules treat notifications on those differently.

Is there an existing mechanism to do this that I may not be aware of?  I presume there must be lots of people that have this same problem.

2 answers

1 accepted

1 vote
Accepted answer

You can try to use IssueManager.getWatchers(Issue issue) to get the watchers in the email template.

Sorry, I'm new to doing JIRA velocity template customizations.  Can you help with how I would gain access to an IssueManager instance in the context of the template?  It doesn't seem to be one of the standard things that would be available from what I can gather in the documentation.

You can try to use below code to get componentAccessor and then do a get for getIssueManager()

#set ($componentAccessor = $constantsManager.getClass().forName('com.atlassian.jira.component.ComponentAccessor').newInstance())

I havent tried it but found a reference from below answers.


Looks promising - thank you!  When I get a moment I'll give it a shot and, if it works, mark your answer as accepted.

Sorry for taking so long to get back to this, but the approach did in fact work.  Thanks for the assistance!

1 vote

It's not a problem that I've seen reported before.

There isn't a lot you can do about it though - the email is not built for every individual, it's a single email sent to lots of people.  There's no way to know why you've been included in it.

Possibly the email could list all the watchers?  I understand that could be problematic if there are a huge number of watchers on an issue, but maybe the list could be truncated in such a case?  Obviously my email routing rules would/might not pick up that I am a watcher in such a case, but I imagine that would be pretty rare if it cut off after 20 watchers for example.

Good idea!  Yes, I think you can get to the watchers, but I'm not sure it's simple.

Email changes are not technically supported, but they're easy to do, and if you do need support, you can just keep the old template files.  See https://confluence.atlassian.com/jira/customizing-email-content-185729653.html

Unfortunately, it looks like the Issue object model referenced for email customizations contains only the count of watchers and not the actual watcher names or IDs.  See: https://docs.atlassian.com/jira/latest/com/atlassian/jira/issue/Issue.html

Is there something I am missing?

I wasn't sure it was that simple.  Some old java code I dug up has watcherManager.getWatchers(issue locale) in it, but I don't know if that can be translated to the .vm

After you mentioned WatcherManager I did another search and sure enough, I am not really the first person asking for this:


The linked thread shows somebody asking back in 2009.  Unfortunately, I've found it hard to find a good set of keywords to identify this type of question without the top search results being just generally about watcher functionality or generally about email notifications.  Searching for "velocity" and "WatcherManager" finds this one but wouldn't find other places where people might be expressing the same general need for a way to prioritize specifically watched items vs general updates received by a team member.

Anyway, it seems WatcherManager is not accessible without an actual code change to JIRA (such as modifying com.atlassian.jira.mail.JiraMailQueueUtils#getContextParamsBody as suggested in the thread).

Yes, I'd be rather unsure about looking at 7 year old stuff as well (unless you're on a 7 year old JIRA).  On the other hand, if it's the Wojciech I think it is, the code is going to be good, and there's no doubt that the Jamie Echlin comments are right. 

I don't know how much it's changed since then, but even if it hasn't, I know I'm out of my depth (I'd like to wave the "I am not a developer" flag here).  I know a couple of people who know a lot more about the internals of JIRA at this level than I do, so I'll ask them.   I still owe Jamie many pints for his help in the past, and I'll happily buy him another one if he can help out here too.

I'm working with Ben on this issue and we have redone all our notification to include system fields ar the bottom of all notification and the last request was to get a list of watchers added to the notification.  We are still interested in getting this to work and here is the current VM we are working with to get all the fields added.


#rowWrapperNormalBegin('' 'wrapper-special-margin')
<table class="keyvalue-table" id="actions-pattern" cellspacing="0" cellpadding="0" border="0" width="100%" align="left">
<tr align="left">
<td id="actions-pattern-container" align="left" valign="left">
<table align="left">
<tr align="left">



Here is the new VM we are creating


    #set ($componentAccessor = $constantsManager.getClass().forName('com.atlassian.jira.component.ComponentAccessor').newInstance())
	#set ($allWatchers = $componentAccessor.getWatcherManager().getCurrentWatcherUsernames($issue))
    #foreach ($aWatcherUsername in $allWatchers)
       #set ($applicationUser = $componentAccessor.getUserUtil().getUserByName($aWatcherUsername))
 	 	$applicationUser.getDisplayName()/($aWatcherUsername) #end

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

221 views 6 0
Join discussion

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