Please fix it, feel helpless.

Teams are complaining a lot because of the bombardment of emails.

This is not working for worklogs. If you would like this to be solved, please vote for https://jira.atlassian.com/browse/JRASERVER-63577

I'm having the same issue that Nick is reporting.

Sending a request with notifyUsers=false under my user with Jira Admin will correctly suppress the notification, but sending the exact same request with our integration user that only has Project Admin sends notifications even when notifyUsers is provided and false. I've confirmed with the permission helper that the integration user does, in fact, have the project admin permission for the issue we are modifying in the request.

david.faure, with ProjectAdmin a notification comes too.

@oleg.pronchenko https://stackoverflow.com/questions/13017931/disabling-jira-notification-emails-for-rest-api-updates/13025457?noredirect=1#comment89310388_13025457 says you need ProjectAdmin or Admin rights for notifyUsers=false to work. For some reason.

Hi everyone

PUT /rest/api/2/issue/{issueIdOrKey}/worklog/{id}?notifyUsers=false

notifyUsers parameter does not work. The notification to email always come

Jira v7.12.0

dmeyer, the com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource#addAttachment method has the following line:

            issueUpdateBean.setDispatchEvent(true);

which sends a notification whenever an attachment is added through the REST API. This notification should be optional.

I have created https://ecosystem.atlassian.net/browse/ACJIRA-1403 for that.

David

NOTE: We are using https://docs.atlassian.com/jira/REST/7.2.1/#api/2/issue/\{issueIdOrKey}/attachments , not sure what other API's might be out there, in case a different one causes it.

What generates the e-mail below then?

TaxSys Software / Development TS-42627
Add a link to upload roll files
Change By: Gitc User
Attachment: TS-42627-visual_sparks_output.txt
Add Comment Add Comment

This message was sent by Atlassian JIRA (v7.2.1#72003-sha1:3448e6b)

Hi klaus.kaisersberger and rlzaleski276419941,

JIRA currently does not send notifications for attachments at all: JRA-1898

Dave

My company tested this with an integration for attachments, this should cover it right?  I can open a new ticket if needed.

This does seem to work for comments.

@dmeyer: Does "notifyUsers" also work for other actions like removing or adding attachments etc.?

It sure is not documented that way, but maybe…

There's a comment from me from June 3. I've updated the issue description to clarify.

That's exactly what I wanted. This issue got closed with no information about why or how to use the new feature

matt.doar could you clarify? The notifyUsers query parameter is documented in the JIRA 7.2 REST API documentation.

Please would someone add a note here about how to use this feature in 7.2

atlassian.com1 it's something we would like to add but we don't have any immediate plans to work on this. I've created a feature request here to track it.

Hi @Dmeyer - will it be possible to suppress emails on all API calls? The documentation link only seems to have the notifyUsers flag on the 'edit issue' API – but we'd really like to be able to give our API the ability to suppress notifications for any change it makes ... especially adding comments (which in our case sometimes act more like an audit log, that doesn't require every watching user to get alerted...)

Hey matt.doar, no the email will be suppressed for all users, not just watchers. We will update the documentation to clarify.

narendran_bhojan and others that asked about available for JIRA Server, as you can see from the Fix Version field, this will be released with the 7.2.0 releases of JIRA Server applications.

Dave Meyer
JIRA Product Management

Dave, the REST doc says "send the email with notification that the issue was updated to users that watch it". Does that mean that the mail is suppressed only for Watchers, not for regular Assignee, Reporter etc as configured in the Notification Scheme?

@Dave , we would also like this feature added to server. Also, we need the same parameter added for the delete issue rest call. We plan to archive old/closed issues through an automation and would like to suppress the email notifications on issue deletion.

+1. We need this on Server.

Wonderful news Dave. I agree with Brian, you need to clone the issue for server when closing only for cloud. This applies to any issue like this in the future once you start diverging like this.

Is there a corresponding issue for making this available in Server? I would assume it would get many of the same votes this issue received.

Hi everyone,

Suppressing email notifications is now possible in JIRA Cloud. We have added a new notifyUsers query parameter to the issue resource. You can set this query parameter value to false when making a PUT request to suppress email notifications for your change. You can view the documentation here.

This will only affect email notifications – changes will still be logged, added to the issue change history, events will still be sent to listeners, webhooks will still fire.

This is currently available in JIRA Cloud. We're not able to forecast when it will be available in JIRA Server right now, but we will provide an update on this issue when we are able to do so.

Regards,
Dave Meyer
JIRA Product Management

Please add this or a workaround for it. I'm attempting to work around Lexorank by providing a human-readable ranking number through a script that runs as a cron job based on massive user demand, but I can't run it because the amount of unwanted notifications updating one of our main projects (with several hundred open tickets) once would probably take down our JIRA server if not our mail queue. Our workarounds now need workarounds.

Please add this feature. Filtering messages on mail server as a work-around.

Please add this feature. It can't be that hard, because it already exists when doing a bulk change in the web interface.

Please add this feature. Currently unable to provide any kind of bulk automation due to unnecessary spamming of users.

+1 Harder to workaround in Cloud as we cannot create our own REST interfaces in JIRA.

We classify this as a near-to-blocker problem, since the amount of mail generated is not only annoying users, but leading to load problems also: Imagine a varying collection of >5000 issues being bot-updated in a batch-run via REST, which results in tens of thousands of e-mails generated in a short time.

Let's not even talk about the wasted space and absolute uselessness of this kind of "notification". All this behavior does is to annoy users and to have them discard any mail from JIRA, rendering the whole notification feature worthless even for cases, where it would surely be desirable to get them. For some push-mail-accounts to corporate smartphones, auto-deletion of JIRA mass mails is not even possible, leaving users with hundreds to thousands of junk mail to manually delete from their phones multiple times a day!

In essence, the criticized behavior makes JIRA a disliked system by many users - and, I have to add: Understandably.

Therefore: You should definitely give the ticket a heavy push!

Another possible solution would be to be able to disable certain fields not to generate mails when updated.

+1. experiencing the same issue.
In our case, the scenario is that files checked in is added to field, and to code set up in case could generate 100 + mails.

+1, this would be very useful indeed

Is there any update on this. This is really a very useful feature.

Any progress on this request?

Add me to the list of people who want to see this implemented and quick!

We are experiencing the same issue, we could really do with this getting resolved to stop email spam on automated issue updates via REST.

Our engineering teams started transitioning the scripts from SOAP to REST. I appreciate if you can get us this valuable feature as early as possible.

This would be a valuable feature.

+1

+1

I would think this is possible since the Bulk Edit/Update allows you to Not Send Emails for those changes. Seems like adding that type of option to the API calls could be somewhat easily.

Yes, it's hard to arrange for JIRA to never send email from one user. I've messed around in the mail-related source code and done it before, e.g. when a user's email address ends in .invalid there's no point in sending any email (RFC2606). I know that Atlassian is concerned about changes to issues happening without people being aware of them, but the current flood of JIRA email is no way to communicate changes anyway. Too many people already filter out all their email from JIRA

Sometimes I want users to see (via email update) the changes my scripts make and sometimes I don't want to bother them with an email. I would definitely prefer to have a parameter I could set on a REST call to disable emails for that REST call rather than globally disabling it for all REST calls or for all operations by a particular user.

+1, this would be really nice to have.

One possible solution to this problem is to have a special group, like jira-bots (or jira-automation, jira-silent) for which jira will skip sending email notifications if the changes were made by a user part of this group.

+1 for this - it would be exactly what we need

Sadly, we can't use the exim solution that intersol mentions as we use Gmail for our company's email. I agree with markhaller, needs to be in the REST system itself.

+1 for this - we've got a pretty complex JIRA importer we've written that pulls in huge MS Project plans into JIRA ... and receiving email notifications for hundreds of tickets across many projects is a pain. Being able to either turn off notifications for a REST session .... or parameter passing no emails per request would be great.

Here is a complex workaround, to configure exim4 to filter notifications generated by a certain user, I use .bot user for automation purposes and I don't want to send notifications to users. BTW, this works only for plain text email notifications. https://bitbucket.org/phoebian/phoebian/src/b7dce5876687ee67d1bd8c65cb89c5e1be2954ce/etc/exim4/system.filter?at=default

+1 for this! Or instructions on how to achieve this.