Make notification emails for new announcements and issues optional in OJS3.0.2

Given the number of past forum posts about disabling announcement and issue emails – as well as the severity of an email sender getting flagged as spam – I think there’s enough to warrant an option for disabling these emails as a high priority issue. @ajnyga, would you be willing to file a GitHub issue for this and bring it to my attention?

I had a look at the Settings > Workflow > Emails tab. I see that there’s an email there for “Publish Notify” that can’t be disabled. Maybe we can just allow the enable/disable toggle to work there, and add a similar entry for Announcements? I’m just guessing, though, as I’m not that well read into the notifications system.


The publish notify template is actually not used at the moment: [OJS] Publish Notify email template not used in OJS 3.0.2 · Issue #2406 · pkp/pkp-lib · GitHub

The system uses the default notification template in all cases.

I can post the issue of course, but what do you think about the discussion we had with @ctgraham above?

Maybe we could do a quick fix now by introducing the option to disable these two types of notifications, but also consider the unsubscribe link option. I really think that @ctgraham had a good idea there and unsubscribe links is something that users are used to.

Many of our journal managers ask for a somewhat contrary option: they need a simple form (email, name) for users to subscribe to notifications for new announcements and issues (without filling out the full registration form). Is it possible?

I just inadvertently e-mailed 500+ registered users of one of our journals with the link to an announcement that I created on our test upgrade of the journal. This was a bit mortifying to have to explain to the journal editor, that this notification went out with her name on it. I’d like to strongly advocate for the quick fix to introduce an option to globally disable notifications for announcements as mentioned by @ajnyga in April, especially since this is a change in behavior from OJS 2.4.x.

(On a related note, in OJS 2.4.x user accounts defaulted to not sending e-mails for notifications, but in 3.0 they default to sending e-mails for everything. One has to opt out of e-mails. Why was this change made in going from 2.4.x to 3.0?)

Hi @hcorbett,

This has been discussed here until very recently: [OJS] Make notification emails for new announcements and issues optional in OJS3 · Issue #2561 · pkp/pkp-lib · GitHub

However, before suggesting any changes to the code I will have to wait for @asmecher comments on the things discussed there. The thing is that they are about to release 3.1 very soon and there are several other issues the developers are probably dealing with at the moment.

However, if this does not make it to 3.1 I will solve this in our installation with an own plugin or a patch, because we constantly get complaints about this from our editors. I can send you the code then as well.

1 Like

Thank you! I’m hopeful that the capability to send/not send notifications will be included in 3.1.

Hi @ajnyga and @hcorbett,

Sorry for the wait! I’ve added some comments on that github issue.

Alec Smecher
Public Knowledge Project Team


Thanks @asmecher, no problem! I added a comment here [OJS] Make notification emails for new announcements and issues optional in OJS3 · Issue #2561 · pkp/pkp-lib · GitHub

pretty much what you suggested with small additions.

Hi @ajnyga,

I’ve been following this issue but maybe I missed something.
The discussion is about optional new issue notifications, but this event delivers a typical notification template, and not the PUBLISH_NOTIFY. One of this fixs is for the optional caracteristic of this notifications. Or applying Make new issue notifications optional by ajnyga · Pull Request #1542 · pkp/ojs · GitHub is what we are talking about?
I notice some differences between that code and the one from ojs_stable_302.

Thank you!
Best regards


Yes, I noticed that the template is not used a while ago as well: [OJS] Publish Notify email template not used in OJS 3.0.2 · Issue #2406 · pkp/pkp-lib · GitHub

I think that the issue in general will need more work later, but in OJS 3.1 there will be some changes that have been discussed here [OJS] Make notification emails for new announcements and issues optional in OJS3 · Issue #2561 · pkp/pkp-lib · GitHub. Basically when publishing a new issue or adding a new annoucement the editor can now choose whether she wants to send a notification email. I think that most are happy already with this change.

I do agree that the notification for a new issue should be a longer email and maybe use the template you mentioned.

Hi @ajnyga,

In [OJS] Make notification emails for new announcements and issues optional in OJS3 · Issue #2561 · pkp/pkp-lib · GitHub I’ve applied Make sending an announcement notification optional by ajnyga · Pull Request #2804 · pkp/pkp-lib · GitHub and it seems great, no problems until now. And that is why I thought the other issue would apply too in 3.0.2 but looking it closer I wasn’t sure about it.
So, and as you said, the publish_notify notification still isn’t working and that issue was only for the optional sending feature!
3.1 will be a great improvement over some features, but in a nearest future 3.0.2 will resist and I’ll have to manage some of these issues.

Thank you for your help,
Best regards

While we wait to get this issue resolved in the next version, can anyone suggest a temporary workaround to stop sending all notifications. This would be really useful for those trying to migrate old publication data to OJS.

If you are using 3.0.2, then you could go to Settings => Distribution => Access and select the option “OJS will not be used to publish the journal’s contents online.”.

Now when you publish the old issues a notification will not be sent because 3.0.2 includes this change: [OJS] Journals with publishing mode set to "none" should not send notifications when publishing an issue · Issue #2250 · pkp/pkp-lib · GitHub

After you are done with adding the old issues, you can change the setting again.

edit: or you could just do a temprorary change to the core code and remove the code that sends the notifications

Great. Thank you very much for the suggestion.

Just to clarify will this stop notifications like announcements, user sign up etc also? Or this setting will only stop notifications for old issues only? Thanks again.

The trick only stops the notifications for new issues.

The fix that is coming for 3.1 will give you the ability to control both new issue notifications and announcement notifications.

Thanks again for the clarification. Look forward to the 3.1 release.

Hi everyone, I am trying to find the most recent thread that discusses the problem with email notifications automatically being sent out to all users for our journal whenever a manuscript is published despite us having unchecked every box in the Notifications Tab for each user. I’m wondering if this issue has been resolved in any way? I see that there has been considerable talk about it for at least the last year?

Thank you!

Hi @JPBirdsCaribbean,

I see you’ve also posted this on another thread – please don’t double-post; it clutters the forum.

Alec Smecher
Public Knowledge Project Team

Hi PKP team,

we had a very recent case on our recently migrated OJS 3.1.2 platform where notifications for an announcement of a given journal where sent to all journal users. Some users had complained.

Please be aware that as the user profile setting for announcements is implemented currently, it is the wrong way round. By default, notifications are enabled, however they should be disabled (with the possibility to opt-in).

The EU General Data Protection Regulation (GDPR), enforced since May 25 2018, requires active opt-in for e-mailings (see e.g. ). The current implementation is in violation of this principle.

Since the notification_settings table is a key-value table that uses an incremental counter every time a setting is added or removed, I see not a straight-forward way to disable all notifications by default (would require adding a few thousand records).

Please, with the next upgrade

  • redesign the user profile implementation so that it is compliant with GDPR
  • provide a script that allows to set user profiles to their correct default notification settings.