How can users disable Jira email notifications?

I would like to disable email notifications for certain events in JIRA so that I don't get an email every time somebody creates an event for me, or comments on one, or completes one I created, or whatever other thing. 

Although I am supposed to be the admin of that project, I don't have the notification scheme option anywhere I can find.  But that's beside the point because users should OBVIOUSLY be able to set these options for themselves individually (because individual's preferences and ways of using JIRA differ).  It's so annoying that we will be switching to a new task management platform if we cannot disable these emails very soon.

Maybe the option exists and I can't find it, in that case please point me to the instructions. Or maybe Atlassian failed to provide this obvious feature, in which case please add this obviously desired feature. 

7 answers

Aaron,

While I understand Nic's arguments and agree with them mostly, I know that reality may be different. In many cases I can see that teams do not rely on the notification emails, but history, activity streams and statuses in the issues. Lots of teams tend to ignore emails if there are many.

A good level of granularity in notifications can be achieved using Notificaiton Schemes in many cases, but sometimes it is still frustrating.

One alternative to fine grained notifications could be to use filter subscription. It delivers emails to you periodically containing issues matching a filter. Filter may be something like "Issues changed in the last hour". With an hour period, you'll get the changed issues without details in the email about what has changed.

Another alternative to the problems you mentioned is an add-on that provides what you need. It is called Bug Watcher Notifications

It allows you to configure your a JIRA project with a minimum or even without a Notification Scheme and let your individual users select their personal notification preferences instead. This includes selecting the individual event types they want to get notified on.

It also allows you to set up in-app notifications. Either in a self-service manner (see above), or using a Notification Scheme that will not deliver emails but in-app notifications.

The full list of features is available too. It is for JIRA Server only not for Cloud though.

That Bug Watcher does sound like the functionality I want, although unfortunately I'm using the cloud version. 

Currently I've just turned off all notifications, but I'd like for my developers to be able to turn them on for themselves if they want them for some reason (like maybe they are traveling or staying home and only working intermittently when there is need) without me needing to adjust the notification scheme in some fancy way. 

Imagine there is one person (who is on another team but sometimes does work for us on demand) who should get an email whenever THAT PERSON is the assignee, then probably I can get that done using roles somehow even if there isn't the functionality of "inform the assignee if the assignee is this person" in the overall scheme.  Essentially making each person their own role and setting the notifications for that role...but I don't know if that will even work the way I'd like. 

Or maybe I can set the scheme to email the assignee whenever the label "notify" is included, but I haven't tried that yet.  That's still not letting the person turn it off or on depending on their current needs, but that would satisfy some use cases that the schemes don't seem designed to support.

Thanks for your advice, I'll try some stuff and report back if I need further assistance/advice on getting it to work with my situation.

Came across this thread and I have what seems like a similar use case to yours.  We turned off all notifications, but hook a message stream into Slack so there is a flowing stream of all activity.  We find it more efficient.  But in our case we mostly do new development, not so much maintenance.  So the number of tickets that are moved from desk to desk is small.

JIRA is showing it's age by relying on email and being dogmatic on how it should be used.  Most of the people I work with simply don't use email for these types of things anymore.

Relying on email?  Rubbish, most of us turn most of the email off, and sit on the HipChat notifications.

I am the adminstrator and I would like some of my colleagues get their notifications on Slack (because internals), and some on emails (because external).

How can I achieve that ?

 

Thank you

There is a great solution to avoid the dozen JIRA email notifications - it’s an add-on Email Notifications Digest that enables JIRA users to group JIRA notifications and send them as a digest at a scheduled date/time.
You will get a single digest email with the updates specifically for you. All updates are grouped by issues and you can easily track who made each update.
It will save your time and a lot of nerves and peace of mind. You can keep a bird’s eye view on important issues and not distract many times during the day.

How it works:
Once Email Notifications Digest is installed and configured, each user in the system will start receiving the digest of recent JIRA updates at date/time configured by the user).

Configuration Page:
you can configure

  • time
  • schedule
  • number of updates

All recorded actions are in digest:

  • Create new issue all issues types are supported
  • Updates to an issue all modifications made in issue fields:
    1. standard fields (
    description, summary, component, affects/fix versions, issue assignee/reporter, due date, attachments etc.)
    2. custom fields (labels, planned start/end dates, user picker, group picker, checkboxes etc.)
  • Log Work
  • Comment to an issue (add / update / delete comment)
    If user is not allowed to see a comment due to visibility level restrictions (comment cannot be visible to JIRA group user is part of), record will not be sent in a digest.
  • Issue State change (start progress, resolve, close etc.)
  • Move an issue
  • Convert an issue to task / sub-task
  • Delete an issue

Amazing. That's basically Trello awesome email notifications system for Jira. Why is this not included by default in the cloud version?

Please Atlassian you bought Trello so make it worth and just include this or at least tell us you're working on this issue!

Hi @Nataliya Vasyliv,

 

I have just tried out the Email Notification Digest, and my problem is that the plugin sends its digest e-mail besides the Jira built-in notification, so users get even more email.

https://activitytimeline.atlassian.net/wiki/spaces/NDD/pages/48502637/Frequently+Asked+Q+A

"

Notification Digest and Jira notification emails

 

Q: Will I receive the email digest in addition to the default JIRA Notification emails or instead of them?

A: You will receive both: default JIRA notifications and digest.

You can setup a rule in your favorite email client to move notifications into a separate folder.

"

Do you find other way to configure it?

Hi Róbert,

Yes, you can turn off default Jira email notifications at JIRA Administration -> Projects -> Project -> Notifications page. 

Open "Actions" -> "Use a different scheme" drop-down and set "Notifications Scheme" to None. Repeat for each project.

In this case, you will receive digest emails from Email Notifications Digest only (per individual user's digest schedule). 

This is just a "me too" here.  I'm a lowly user - not an administrator.  My coworkers make incremental changes to issues that are assigned to me (or that I'm tagged on or whatever) when they have time and are in the mood.  My InBox fills with 28 emails with little pink strikethroughs and rewordings.  But I'm working on something completely different.  In a week or three, I'll log in and see what my current to-do list is on this project.

Please provide a way for an individual user to say "No email notifictions for me, thanks!"

I've got a workaround in mind that should do the job for now, I hope!

One workaround for this can be, even though you are not the assignee, you might be in the watchers list for the issues. So removing yourself from watchers can work.  

search for the issues that you are watching using the JQL

watcher = currentUser()

this will return all the issues that you are watching right now. from the list, you can delete yourself from all the issues that you don't want to watch. 

Hope this works for you

-krishna

0 vote

You need to go over the notification schemes with your administrators to make them more fit for your needs.

Remember that JIRA is about sharing, not getting totally different sets of information because you don't feel like seeing what your co-workers do - the schemes mean people get consistent behaviour and know that others are getting the same shared information.  But they are a bit noisy by default.

Problem 1) Supposedly I am the administrator, but I don't have access to the notification schemes.  I'll look into that with the person who actually did the purchasing and setup.

Problem 2) Facebook is about sharing too, but not everybody needs/wants to see everything that everybody else does.  People have their own preferences and there are many different use cases.  And for our use case we prefer being able to assign, watch, and complete tasks while in the JIRA dashboard without ALSO getting worthless emails about all the activity we just did/saw on JIRA.

Problem 3) Unless there is an option in the notification schemes to allow individual users to set their own notification preferences, JIRA fails to delver the product we want.  Some people work at home and/or part time and will want the emails so they know when there is something for them to do, others are working with the dashboard in front of them and the emails are annoyingly redundant. Consistent behavior in the way you describe only makes sense if every user in every use case is the same in their needs/preferences, and that is often not the case...at least it's not true in our case.  Assuming I eventually figure out how to access the notification themes, does such a capability exist?

Problem 1 Solved: The person couldn't easily figure out how to transfer all the privileges, but now that there is this reason to, finally figured it out.

Problem 2 Frustrated: After eventually finding the notification options, I see there isn't one to let the users decide, which is a disappointment and a pity.  Also, there doesn't seem to be any way as the admin to set up what I want either.  For example, I can set either the assignee as an email recipient OR a single user (who it seems would get an email for every new task regardless of the assignee, but I'm not sure)...

...but what I want is for a particular list of assignees to get emails (while the rest do not).  There doesn't seem to be any functionality to set up that kind of contingency, but maybe there is a way to achieve this with the available options that isn't clear to me.  So, any advice on how to do that would be most welcome.

JIRA does support "send email to one set of people and not another" in the notification schemes - the best option is to set it up for any particular event to be sent to the right people.  I usually recommend going over each event and thinking about who needs to get it individually - the default of reporter, assignee and watchers is often too noisy (for example, the reporter and assignee usually have no interest in people logging work, so I drop those two from the work log events), and there are cases where everyone is interested, and I would add roles to the schemes (I use roles so that the project administrator can add and remove individuals or groups).  For example, when a new issue arrives in a dev project, you want to tell the developers - use "issue created: role (developers)".

But the point of the notifications is to tell people that stuff is happening.  Consistently.  The users can not turn off notifications just because they feel like it.  They should work with the admins to come up with a scheme that works for everyone (even if it's "send no email", or "only email people in role X"), but they can't do it for themselves because then you have no idea whether someone who might need an email is actually getting it.  It's a poor attempt at collaboration if your whole team expects an email to drive something and you have one person who turns it off and can then be ignorant of what the others got.

But if the ability to randomly lose your expected email is a deal-breaker, then yes, you need to go elsewhere.

Your use case seems very different from mine, and your concerns seem different as a result. What I expected to find in the notification schemes is that the admin could assign certain notifications as "user's choice" and then the user could choose what notifications to get and turn them off and on depending on their immediate situation/workflow.  The admin could also set the notification scheme for certain tasks/events/etc to push to everybody and not let the users choose.  That would prevent the case you are worried about and also not require the admin and task creator to know the preferences of every user and whatever complicated notification scheme involving roles and labels that is required to get the notifications correct.  It seems a simple and obvious thing that at least some people want and I am surprised that the option doesn't exist in a product as mature and popular as Jira.

"They should work with the admins to come up with a scheme that works for everyone "

 

There is no such scheme.

So the de facto solution is for users to individually re-assert control by seting up email filters that auto-trash everything with JIRA in the subject.

Well, I'm afraid that's completely wrong, because I've loads of people with schemes that work fine.  Because the admins have listened to the users.

Auto trashing is completely understandable.  But also totally the wrong approach.

Perhaps a story would help.

 

At my last employer we DID talk to the admin. Some coders felt their jobs depended on getting up to date notifications. Others, on the same team, had no use for them as they only focused on their assigned task.  Still others had no use for them then, but would have liked them after product-launch.

"No Problem", said the admin, "I'll just make it so you can adjust your own email settings."

A few minutes later he emerged from his office and said "Guys, you're not going to believe it, but JIRA doesn't even have that functionality!"

Two years later, I still don't believe it. 

Now I'm sure someone will point out how we could have reoganized our team or fiddled with some other settings or something, but the point is that it would be a total non-issue if JIRA had a piece of basic functionality that, nowadays, is considered standard and is expected for basically any online software.

There is an easier way to give everyone control.  Tweak your notification scheme so that the notifications are set to All Watchers.   Then, if you want notifications, on a specific issue, watch it, otherwise, don't watch it.    Those that want email can choose to watch.    

 

As for us, we have taken the time to create roles/groups, and use those for notifications.  Yes, some people get notifications they don't want, but we worked with each group of users by role, and determined what they felt would be worth notification, and what wouldn't.   We have an organization of about 500 users, and this works for us generally.  

 

One workaround for this can be, even though you are not the assignee, you might be in the watchers list for the issues. So removing yourself from watchers can work.  

search for the issues that you are watching using the JQL

watcher = currentUser()

this will return all the issues that you are watching right now. from the list, you can delete yourself from all the issues that you don't want to watch. 

Hope this works for you

-krishna

0 vote

Well for me it is very obvious that users should make those settings for themselves.

 

In reality you can't force people to get those notifications if you want them to. Some may like them some may not. Some schemes may be good for some and for others they are not.

 

If you try to force them but not giving them the option to change it people will just add mail client rules to delete them and what is the point of sending 1000 of mails which nobody is going to read ?

 

So not giving the user the option to make their own settings is just working around the user needs and bad by design. And in the end it will not achieve anything just more addons or rules that filter those mails.. and just more data trash overall.

 

So please add this feature which you already had in Jira years ago.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,321 views 14 20
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot