OJS3: notifications, sender and reply-to address

Tags: #<Tag:0x00007f670c3168c8>



After upgrading to OJS3 (now in 3.0.2) I started to have a lot emails from the users of our journals which were basically replies to notifications they had received. This is due to the fact that in many notifications the reply-to address is set automatically to site contactEmail. This is the case for example when a new issue is published.

Also, in many cases the sender of the notification is also set as the site admin account, instead of the journal user accounts.

Is this intended and why?

I noticed that in some notifications OJS checks if a context is present: https://github.com/pkp/pkp-lib/blob/ojs-stable-3_0_2/classes/notification/PKPNotificationOperationManager.inc.php#L289

But in other cases it does not: https://github.com/pkp/pkp-lib/blob/ojs-stable-3_0_2/classes/notification/PKPNotificationOperationManager.inc.php#L450 and https://github.com/pkp/pkp-lib/blob/ojs-stable-3_0_2/classes/notification/PKPNotificationOperationManager.inc.php#L329

Is there a reason behind this? I mean, it would be easy to check for context like on line 289.

Answering notification to journal administrator and not site administrator

Hi @ajnyga,

Some operations are considered journal-specific – most of them, in fact – but some are considered site-level, like password resets. Notifications are a bit of an odd case, because the same mailing code is responsible for a large number of different types of notifications. Given that you’re running a fairly typical service provider type of service, I’d be interested in more information on what your expectations are. Is the problem that you (as the site contact) are receiving messages that would be better directed to the journal contact? Are the problem messages specifically notification messages?

Alec Smecher
Public Knowledge Project Team



I see your point.

I think that the most cases where journal users have contacted me while meaning to contact someone in the journal have been the cases where a new issue has been published.

This notification uses the default notification template ($this->getMailTemplate('NOTIFICATION')) but it is a message I think should come from a representative of the journal.

In this case both the sender and the reply-to address is site specific, not context specific, and at least in my opinion they should be context specific.

Another case (which I have the check tomorrow) is that many of notifications going to for example editors have a reply-to address of the site contact. Here as well I think that the reply-to address should be the context main contact.


@asmecher looked trough my email and found at least these cases, where the signature of the notification is context specific but the reply-to address is the site contact:

Notification: An issue has been published.
Reply-to address: site contact
Signature: context main contact

Notification: A new announcement has been created.
Reply-to address: site contact
Signature: context main contact

Notification: All reviews are in and a decision is needed in Review.
Reply-to address: site contact
Signature: context main contact

Notification: You have been added to a discussion titled etc.
Reply-to address: site contact
Signature: context main contact


Hi @asmecher

I keep on getting a lot of emails that are supposed to go the journal editors.

The most recent one was a respond to a discussion between the editor and the author. The author responded to a notification about an update in a discussion. The message is signed by the editor, the sender address is the editor’s address, but still the respond comes to my email. This does not make much sense.

I actually started to think that besides password changes, what are the other notifications that need to be site-level? And why can’t even the password changes be signed by the journal’s technical contact?


Hi @ajnyga,

I can think of two easy solutions:

  1. Make certain kinds of emails use a no-reply address and contain a “do not respond” note. (Discussion notifications are good candidates for this, because we want to strongly discourage out-of-channel conversations, as they break the audit trail.)
  2. Make certain kinds of emails come from the site contact when outside of a journal context, and from the journal contact when inside a journal context. Password reset and notification emails might be good candidates here.

Alec Smecher
Public Knowledge Project Team


Thanks @asmecher

Regarding 2, the sender is really not a problem here. The sender address is usually what you would expect (see OJS3: notifications, sender and reply-to address). The problem is the reply-to address that is in many cases the site main contact address. The problem with the reply-to address is that you only see it when you start to answer an email and usually you do not notice that it is actually different than the sending email.

What I was thinking about is to always use a context specific reply-to address if a context is available, like this: https://github.com/pkp/pkp-lib/compare/master...ajnyga:use-context-specific-reply-to?expand=1

Regarding 1, I do think it is a good idea to have the “do not respond” tag there. Should that be in all notifications (meaning that the change would apply to the NOTIFICATION template) or should it only be in the case of discussions? However, if you are suggesting using a no-reply address like "no-reply@email.com" then I think that this is something that is usually discouraged?



Is this really not a problem with other multijournals installs using OJS3? Today alone I have received seven emails as responses to notification messages that I have to forward to the correct editor. One of the responders noticed that the reply-to address differed from the senders address (the editor) and got scared that this was some sort of security issue.


Hi @ajnyga,

On balance I think your proposed solution (to use a context-level reply-to when available) makes the most sense and is easiest to explain. Would you mind opening a pull request from your branch above if it’s ready?

Alec Smecher
Public Knowledge Project Team


Thanks @asmecher,

Edit: I do think that having a “do not answer this email” tag would be good as well, but I guess that would have to be organised so that it gets into all translations.

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

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!


OJS 3.1.0 introduced a change that allows you to choosen whether you want to send the “new issue” notifications
OJS (latest release) introduced a new user setting that allows a user to opt-out of new issue and/or new announcement notifications.


Hi ajnyga,

Thank you for the reply.
We have recently updated to and unfortunately the problem persists. In the attached photo you’ll see what settings we have the notifications on for each user; however, we just uploaded another manuscript and every user received this email: **A new article, “Quinze nouvelles especes d’oiseaux observées en Guadeloupe (F.W.I.),” has been submitted.**

Any thoughts?

Thank you!


Sorry I misread your original message.

All users that are editors should get that message.
Have you tried selecting both the checkboxes under “A new article, title has been submitted”?


Hi @ajnyga, thank you for your reply.

The problem that we are having is that every one of of our USERS is receiving notification emails even though we have un-checked all of the notification boxes in each of their user profile settings. And so we are thinking that there might be a more fundamental problem here that we are not understanding.

In the Settings > Workflow > Emails tab, I am noticing that we do not have any control over the Notification Email options. Please see the screen shot that I have attached below. You will see that the on/off check box is a light gray color that we cannot change.

Any additional help would be very much appreciated. Thank you!


Sorry I missed this answer.

So are you saying that for example users that only have for example the Author role are receiving notification emails when someone else sends a new manuscript? Can you double check that these users do not have any other roles in the system. Because that is not supposed to happen and have not seen anything similar before.

The notification about the new submission should only go to the users that have the editor role and to the authors of the submitted manuscript.
The users with the editor role are fetched here: https://github.com/pkp/pkp-lib/blob/ojs-stable-3_1_1/classes/submission/form/PKPSubmissionSubmitStep4Form.inc.php#L118 and the notification is then sent a few lines below.
The authors are defined here: https://github.com/pkp/ojs/blob/ojs-stable-3_1_1/classes/submission/form/SubmissionSubmitStep4Form.inc.php#L54-L85

So I can not see any obvious reason why users without the editor role and not related to the submitted paper in any way would get the notification.

@asmecher do you have an idea what is going on there?


Hi ajnyga,

Great suggestions. I think we’ve found the problem. We were having our users change their email notification preferences, which we thought would be enough, but indeed we had to go into their user “roles” to uncheck the Journal Manager option, to which it seemed that many of them were defaulted to. Probably a remnant of the upgrade to our new OJS version. Easy fix now!!!

Thank you so much,