Glad this is done... Now how about those service desk notifications and batching? Like even a minute or two delay would save me a lot of emails.

Absolutely awesome!

Fixed after 16 years. Someone tell Greg that this is fixed.  

Atlassian Update – 4 July 2019

Hi and thanks for all your feedback on batched email notifications. We've improved the experience in Jira Server and Data Center 8.3 (to be released soon).

The main changes are:

• improving batched notifications containing mentions
• adding instance-wide delay configuration for admins

Email notifications for mentions are still going to be sent immediately to the mentioned user, but we've eliminated redundant information in batched emails. Until now an additional batched notification was sent to the users if they were also Assignee, Watcher or Issue Reporter, sometimes containing the same information. In the improved experience users will not receive duplicate batched notifications. The batched email will be triggered only if there was an additional issue update apart from the mention itself.

Based on your feedback we have also added instance-wide email batching delay configuration for Jira admins. The available delay times are 2, 5, 10, 30 minutes and 1 hour. This can be configured in Jira settings in the 'Batched email notifications' section where you can also enable/disable notification email batching.

yevgen.lasman1053119404, to answer your question, we have no plans to implement recipients limit in the Send email feature. 

Katarzyna Derenda
Product manager, Jira Server

Any plans to implement batching (50 recipients limit) in Send email feature?

Hi @Katarzyna Derenda - That looks fine! Is there the possibility to switch this option off? So you choose if you batch them or not. And is there the possibility to change the order of the notifications in the batched mail? (one of our customer is asking about this)

Thank you for spotting the mistake in date daniel.schoeneck, I've corrected this in the Current Status.
Thanks all for providing your feedback on making the delay configurable for both admins and users. We'll consider this and combine with feedback we receive after 8.0 release.

Katarzyna Derenda
Product manager, Jira Server

You should change the date of your announcement, it says "2018"...it is a bit confusing

test

Jira Cloud issue: https://jira.atlassian.com/browse/JRACLOUD-1369

Martin Baum, use the Stop Watching button to stop getting email notifications if you don't want them. There are two issues about this, one cloud and one server. I believe the cloud one was where you first expressed your frustration with the notifications. You need to stop watching this ticket now, too.

I also think both admin and user options make sense. In our case, the admin would set this value to 5 of 10 minutes, a good value for most users (e.g. the developers). Other user groups, for instance the stakeholders, who do not need realtime updates, could set it to 1h or even more (one working day), to avoid getting several emails a day when the developers are actively working on a ticket.

Still getting notifications from this. Please stop spam my email

Still getting notifications from this. Please stop spam my email

I agree with Philippe, Jason, and Cory.

"Admins can set the value of the default, and users can choose to set it to a different value if they want."

I agree both admin and user options would be ideal for us. The current default Language preferences as Philippe mentioned is a perfect example of this concept already in the app today.

In smaller businesses it may be simpler to educate users how to modify their user specific email preferences, but in a business at scale, this is less so. The benefits for an admin to establish a "Default" set of email digest settings across the application would be more fitting for an enterprise.

If you were to choose who can configure the batching interval: users or admins, who would you choose?

I second the "both" option. Admins can set the value of the default, and users can choose to set it to a different value if they want.

If you were to choose who can configure the batching interval: users or admins, who would you choose?

What about both?

How does Jira handle the default Language? Who would you trust to set Jira's language?

If the user has set his preference, that will be taken. Otherwise, it will take the system default, set by the administrator.

Katarzyna, user-configurable batch intervals would be ideal!  I'm also glad to hear that the user can still opt out of notifications of their own changes.  Thank you.  This feature of email batching addresses a significant pain point for our organization.

@Katarzyna Derenda, Thank you for the info.  This is great news.

Thank you for all your questions. Let me add some more context and info.

reece5, the new look and feel of emails is specific to batched notifications. If you decide not to enable this option in Jira 8.0, you will keep getting the same format as in 7.x.

richard.burstiner364976502, nwheaton1, we’ve decided not to give admins the option to adjust batch increments for the time being. This decision was mostly due to the fact that we’re also considering adding user-configured batching cadence, which would override the instance-wide default one. If you were to choose who can configure the batching interval: users or admins, who would you choose?

Regarding the question about own issue changes, we keep the current functionality as is. Every Jira user can choose whether Jira should send email notifications or not in their User profile > User preferences > My changes. If you disable the notifications in the user profile and your changes are the only ones made, you won’t receive an email update after  batching is enabled.

aaron75, thanks for your suggestion, the capability we’re shipping with Jira 8.0 is not batching updates for different issues. We do provide an API so that apps can provide batching for bulk issue updates, but we’re not offering it in Jira now. We are also not distinguishing who made the updates, only look at the time frame of changes.

mki1, please watch the corresponding suggestion for Jira Cloud for updates. 

I know it is late to give a suggestion here, but I wanted to throw something out after reading the description above.

Suggestion: When an ticket is updated it starts a countdown timer for 2 minutes (configurable?).  Additional updates to that ticket by that user within the 2 minutes are trapped and merged together as a single email update when the timer expires.  Updates by other users are not merged with these, but with themselves.  Updates for other tickets are not merged together with these, but with themselves.

This would solve the core issue of getting numerous emails for a single ticket when someone comments, logs work, updates the workflow status and commits some code, but would still provide distinct notifications when different users update a ticket and move it through a workflow.

I am frustrated by the chattiness of JIRA, however, I can imagine missing key info if updates to different tickets are batched together in the same notification.  I'm sure this solves the issue for many others, however as described for 8.0 we probably won't be able to enable this feature for our organization.

+1 to making the interval configurable.

Even more importantly, if I'm the only person to update an issue in a 10 minute window, I would not want to receive a change notification from Jira (assuming I disabled notifications of own changes in my profile).

Can you include a number variable on the screen to allow us admins to determine whether we want, for example, 5, 10, or 15 minute batch increments? The default can be 10 but please allow us to determine our business requirements. You can have a value validation to only allow between 1 and 60 minutes if you want.

Are the new email templates specific to batched notifications, or will these templates be coming to non batched notifications too?

Will this feature be available in Jira Cloud ???

Thanks, Reece!

Email batching will be part of Jira 8 for those of you not aware:

 Batching email notifications

I agree, @vlanovets1065279162 solution would be great.

Vladim Kovalenko /@vkovalenko said:
With that said, I agree that Update/Edits get too chatty and getting an hourly/daily aggregate would be more optimal.
Please take a look at comment-1673270, this is optimal solution in my opinion

We took an initiative and upgraded our "Email Notifications Digest" add-on to support "Issue Digest" mode.

The add-on waits and collects issue updates for several minutes before sending; then sends them aggregated in a single email (per issue).

It is possible to filter issue updates by issue field or event type, customize them per user.

Also, the add-on supports defining some projects as Priority Projects (mentioned by Vadim) and send all of their updates immediately in Instant Updates (e.g. for Service Desk projects).

Last but not least, the third mode called "Summary Digest" collects updates from various issues within a day and sends them in a single email per defined schedule (less frequently).

Sorry if this sounds too commercial but hopefully it will be of use to some.

Gotcha, that makes more sense.  It was sounding like you were getting individual field updates during the transition.  As for alerts for transitions, it depends on the project for us. Projects that use a 3rd party mailing system don't have "Generic Event" set, projects that don't have 3rd party mailing, do have it set but even then it's minimal. Now if someone gets click happy, yes there will be a ton of notification, but I personally haven't experienced that yet.

I came across the thread and it sounded like most complaints were from overall mailing, not just updates/edits, which can be greatly reduced with custom schemes.  With that said, I agree that Update/Edits get too chatty and getting an hourly/daily aggregate would be more optimal.

At the same time for some projects and some fields I still want instant updates, getting a delayed alert would be very bad in this situation.  This is where this gets harder to please everyone and I understand why Atlassian hasn't implemented this, they defaulted to over alerting then risking you missing an important update.

I didn't say we got more than 1 notification for a single edit/transition. I'm saying that someone transitioning through the workflow of a single ticket, whether inadvertently or not, can easily generate 30-40 e-mails in a minute or less.  one thing it looks like you're actually not notifying on is transitions themselves?

I am not interested in turning off notifications to a lesser degree and having needed notifications not be sent, we've obviously already minimized who gets what. What's needed is a buffer to buffer sudden changes into one e-amil, which is what this task is for.

That's really odd Dane, I've never seen something like that in our environment.  My users generally complain the issue/comment edits and work log related emails, which is what led me to develop a scheme similar to one I mentioned above, we never get more then 1 email for a single edit/modification/transition though.  Even when the Generic Event was set to all watchers on workflow transitions, the fields modified with post functions were all bunched together into the single email.

Out of curiosity I just tested this in my environment:
First configured Generic Event, Issue Updated, and Issue Commented to notify all watchers.  I then setup a post function to show me the edit screen and automatically update a mixture of system and custom fields:

"Update Issue Field" = Modify Priority, Description, Assignee
"Update Any Issue Field (JSU)" = Copy from custom field to Assignee
"SIL Post-function" = Modifies a custom field and then sends more customized emails

With my test user I ran this transition, in the transition screen I modified an another custom field and added a comment.  Jira sent me only one email for all those changes and that transition, I can't attach image but here is a code paste of it

Comment during approval
ProjectA / PA-001
test
Change By: 	User, Vadim
Priority: 	-Major- +Blocker+
Assignee: 	-User, Vadim- +Vadim+
Status: 	-Pending Manager- +New Status+
-Description- +Test+

(minuses show values removed, pluses shows values added)

Since the default email templates don't know about custom fields, it doesn't include them as part of most events. The only exclusion to that is, when you edit those custom fields by hand, Issue Updated notification does notify about custom fields changing.

We updated our notification schemes as Vadim mentioned and it worked perfectly. 

Since Jira allows you to define the events which trigger emails, and who should be notified for each type of event, this provides much more granular control over the all-in-one "watch or not watch" solution we were using before.  So far we have had great success and I would strongly advise others to do the same and take advantage of these existing notification schemes.

Note: As I'm editing this and realizing that every single member on this issue as a watcher is going to get a needless update.  To solve issues like this you could simply disable edit, forcing people to only submit a new comment for meaningful updates instead of just minor ones, or just add yourself to a group that does not get comment updates.

That actually wasn't an exaggeration, at all. A single ticket can generate that many notifications in under a minute, it happens all day long from where I sit.

That's a bit of exaggeration, but I did check of few of my other projects (that use post functions to modify fields) and I had Generic Event blank there, so removed it from the use case above.

In your scenario you could have still have those notified as a watcher and would still be receiving 30 e-mails related to a single workflow progression of a single ticket.   Not helpful.

My point was, you could help reduce most of the useless/fluff notifications TODAY, by modifying updating the notifications schemes. Then you don't have to wait for another 15 years for Atlassian to actually implement it (guess I'm jaded by how long feature requests actually take). 

For example, I use something like this in my projects:

Issue Created - All Watchers, Current Assignee, Reporter
Issue Updated - All Watchers, Current Assignee, Reporter
Issue Closed - All Watchers, Current Assignee, Reporter
Issue Commented - All Watchers, Current Assignee, Reporter
Issue Comment Deleted - Current Assignee, Reporter
Issue Reopened - All Watchers, Current Assignee, Reporter
Issue Deleted - All Watchers, Current Assignee, Reporter
Issue Moved - All Watchers, Current Assignee, Reporter
All Other Events - NULL

This greatly reduces the amount of typo edits, or redundant notifications for things like Resolved vs Closed, or worklog notifications that no one cares for.  You still have to fight through the field update notifications, especially when done through inline edit (which hopefully will be fix as part of this).  I also make sure that "System -> User Default Settings" have "Notify users of their own changes = No", which even Atlassian doesn't in this specific project (because I just got an email for my own post).

Anyway back to hiding I go, where I have to write scripts to get meaningful email notifications when they are actually wanted.

Totally agree with Dane.  I'm looking forward to Atlassian's solution to this which seems to be in-progress.  What they did to address Confluence updates email chattiness worked pretty well.  Hopefully they end up with a similar solution on the Jira side of the house.

and I think your suggestion Vaqdim Kovalenko is not really a good one, and doesn't address the issues others are experiencing.  This is one of the most top voted requests by the Atlassian community. If you don't want this fixed, focus on voting on something else you do want fixed, but don't tell others what is or isn't important for them.  Removing watchers from notifications is NOT the same thing at all as what is being requested (and is already in the progress of being fixed).

This is by far our #1 with the entire Jira system in terms of user complaints, and it doesn't even come close to having a #2 that's near it.

I think most of the email complaints can be fixed with custom workflow scheme, just remove All Watchers from most of the notification items. The main one that's not fixable with schemes is edit notifications, because of inline edit.  One way to fix that is to disable inline editing...  But since inline editing is so nice, I think the next best thing is to aggregate the issue edits and send out the notification on all of those edits after 10-30min.

Besides aggregating edits, or disabling inline edit, I think your time is better served creating better/more manageable email templates, that don't require system modifications.

Our employees are increasingly displeased with the flood of mail.
When will the solution be available as a release?

>> It is going to be one of the upcoming Jira Server releases.

Great. So those of us who use Jira Cloud will get no relief. Unbelievable.

Fully agree with @Vyacheslav Lanovets

@Katarzyna Derenda, this simple change (5 minute hold off and then grouping) is all that is needed to solve the vast majority of the complaints. If I could get 1 email per task update rather than 5, I would be very happy. 

Make the hold off period user configurable and you're done.

@KDeenda thank you for finally working towards a solution.

I agree fully with @Vyacheslav Lanovets.

@Vyacheslav Lanovets. I couldn't agree more with that. One notification for all changes on one issue within 5 minutes! Been requesting this forwhat seems a decade.

@KDeenda

Batch updates about many issues at once is a nice feature, there are paid plugins doing this. I am sure your other customers will be happy that you have saved some money for them.

We bought many plugins for Jira and Confluence already. We have licence with big user count, but we can buy one more, but there is no plugin for us.

If exactly one user made many changes to exactly one issue within some small time interval, I would like to receiver exactly one notification email, skipping all intermediate changes.

I am not interested in people fixing typos, adding and removing wrong attachments (S!), changing Affected Version, then Component, then Assignee, then Priority, then Labels then Environment, then Environment again, and some custom fields too. All within 5 minutes.

I want just 1 email per 1 issue.

Thanks.

lschmandt, reece5, we cannot commit to a specific release date at this stage, I will update the status once we are ready for release. It is going to be one of the upcoming Jira Server releases. We may also choose to ship the solution in milestones, this will also be reflected in the updates here and the respective release notes.

avento regarding the API for batching email updates triggered by a specific event, I can also promise an update once we finish testing the intended solution. If you'd like to share more about your use case, please share here or email me at kderenda [at] atlassian.com.

casper.roubos1, thanks.

Any improvement after so long will be most appreciated.
:raised_hands: