Closed NateWr closed 3 years ago
NateWr
commented
3 years ago And one more question: what should be the default? Should we ship our software with this feature disabled by default? Or should we disable some user roles (like readers) by default?
marcbria
commented
3 years ago Hi Nate,
I loved your last 3.3 demo but this feature was a surprise to me and since then it don't let me sleep. ;-) But now that I read more about it and I see your arguments against, I find peace in my soul again. :+1:
Long story short: I full agree with your analysis and IMHO, the downsides of this are more important than the potential benefits. So if this feature is going to be included, I would suggest adding limitations mechanisms by default and only let the admin be able to enable it.
You summarized it perfectly, but let me add a few more lines to illustrate the dimensions of the problem:
Imagine you have a single OJS with a 20 journals mailing from same IP (quite usual configuration). If one journal (only one) make a wrong use of the feature (and I see multiple reasons for a wrong usage), the mailer IP will be banned and the whole system won't be able to mail again. And as we all know, take your sever out from a black list takes a lot of time... (if it's possible).
So, from my experience in a multi-installation with 50 journals, if we give our Editors this tool today, I can promise 4-5 of them will use this in the wrong way in the next 6 months... and bigger is the installation, bigger will be the risk and the impact.
I also see the benefits (mailing all reviewers about great news, or section editors about new instructions...) but this can be accomplished with a CSV extraction without compromise the mailing server.
So, as said before, my suggestion here will be:
Thanks a lot for your work Nate. As I always say, it's impressive.
Cheers, m.
marcbria
commented
3 years ago I missed to give my two cents about the "User unsubscribe" option...
When thinking in this "unsubscribe" feature, I will suggest focusing in readers, authors roles (the ones less bounded with the journal) that are the ones that won't like to get more info from the journal.
With them in min, I think we must include a "unsubscribe" option in all mail footers to make extremely easy to remove yourself from a mailing list you don't like to be, but I won't spend much time in creating a taxonomy of mail notifications that only 1% of the users will use (how may people do you think will log into the system, find this setting and read and understand the mail taxonomy descriptions to select the right ones?).
Let me clarify this is my opinion, as feedback to let PKP team decide, but as an additional argument to make it KISS is with all the fronts open we have, I won't spend much time in a more detailed solution.
Take care, m.
openacademia
commented
3 years ago Hi Nate,
Happy to hear this feature will make a comeback! It was possible in OJS 2, which was quite useful – especially to be able to send alerts to Readers only. As you all know, the current Announcement feature sends and email to all registered users which makes the checkbox on the registration page (Yes, I would like to be notified of new publications and announcements.) rather useless as there is essentially no way to opt out. For GDPR purposes we have therefore not used the Announcement feature and have really wished for a way to communicate with Readers only for New Article Published alerts etc. (we have just resorted to Twitter instead)
Our editors have also expressed a need to send an email to all registered Reviewers. Not to spam them with messages, but to once per year in Dec/Jan thank them for their help in the past year, ask them if they wish to remain on the Reviewer list and to prompt them to update their details (reviewing interests etc.) if necessary.
Emailing all authors has never been something we have heard editors express a wish to do and it was not something we ever did back in the OJS 2 days either. I feel like there is a difference in signing up as an author to submit a manuscript to a journal vs. signing up as a reviewer. As a reviewer of a particular journal, you have in a sense made a commitment to that journal and should not be upset by an email every now and then, whereas an author can sign up, submit a paper, have that paper be rejected, and then move on to another journal never to return… Of course, many reviewers do not sign up themselves but are instead added by an editor, so they will not have had a chance to opt in or out of messages from the journal. But again, NO ONE can really opt out, since the Announcements go to all users, not just readers. (this is a larger problem that we have raised many times – perhaps it has been fixed in OJS 3.2?)
In terms of limiting who would be able to email users in bulk like this, I think this brings to light a related issue that was also lost with OJS 2 – the difference in access level between a Journal Manager and a Journal Editor. Typically, the editor in chief of a journal will need to have access to all manuscripts, not just the ones he/she is assigned to. Therefore, he/she needs the Journal Editor role. However, not all chief editors would need access to journal settings, website management, user management etc.
In the best of worlds, I think that sending “bulk emails” to a certain group of users would be something that only a Journal Manager could do, but it might not always be ideal for the editor to have this access. I know this raises a larger issue of access, but I wanted to mention it in this context. It would be best to have different permission levels/access for JMs vs. (journal) editors in my opinion.
Sorry for going of on a tangent of pointing out these larger issues. Here are my two cents about the current way one could limit access to sending bulk emails to users:
Enable/disable per role A setting in the admin area that allows an admin to restrict which roles can be sent an email.
This sounds like a very sensible solution. The possibility of emailing all Readers should be there by default in my opinion. I mean, they have literally asked to be contacted about journal news and new publications so it is hard to understand why this is not already possible. Again, the Announcements feature cannot be used because it sends the announcement to ALL users + journals that publish articles continuously would need to unpublish/publish the entire issue each time a new article is published in order to trigger the notification.
Aside from emailing Readers, it would be useful to email reviewers annually or biannually in order to thank them and give them a change to remove themselves from the database, or add their reviewing interests if they wish to remain. I realize there are GDPR issues since many reviewers have not signed up themselves, but being part of a journal’s reviewer pool hopefully means that they can tolerate an occasional email. For the journal we work with, we have added (in small font) a text in the footer so all emails sent from the system lets the recipient know how to remove themselves from the system. For example:
https://polarresearch.net/index.php/polar/privacy PRIVACY NOTICE: You are receiving this message as you are a registered user of Polar Research. If you have received this email in error or would like your details removed please contact us at Polar_Research_Support@openacademia.net mailto:Polar_Research_Support@openacademia.net
Not as good as an unsubscribe feature, but it works pretty well (and makes people feel less like victims of spam).
I think a combination of the first two suggestions would be great, i.e:
Enable/disable per journal/press/preprint server
Enable/disable per role
The need to email all registered authors is likely rare. I mean, authors of an article published 10 years ago would be surprised to receive an email from the journal 10 years later. Reviewers is a different story where there is a legitimate need not only to thank them, but to keep the reviewer pool updated – to weed out anyone who is not interested in reviewing or might have moved or even died.. It can really help a journal to keep its turnaround time/review time quick, because the no. 1 problem with drawn-out reviews processes is that the invited reviewers do not respond to the initial request. If the editor has a lot of manuscripts to look after, he/she will not notice that a manuscript has been cursed with completely unresponsive reviewers since the status message will just read “A review is overdue” (when in fact, the reviewer has not even responded at all). Sorry, I got lost on a tangent again! =)
To sum up:
*The first two suggestions seem very sensible!
*There is a real need for journals to communicate with Readers who have literally asked to be contacted, but cannot be (see comment about Announcement feature)
*Emailing all registered authors should rarely be needed. It seems like something that would be relevant maybe in a journal’s first year of existence, but after that it seems weird to email old authors. (the author database is “dead”, so to speak)
*Emailing all registered reviewers is another matter completely and much needed as the reviewer database is a tool/important part of the review process. Being able to email reviewers annually/biannually would be a good way of keeping the database up-to-date and to allow folks to remove themselves from the list or add reviewing interests etc. (the reviewer database is “live”, so to speak)
Best wishes,
Emma
Emma Csemiczky
Co-Founder/Publishing Consultant
Open Academia
Skype: emmacsemiczky
Email: mailto:emma.csemiczky@openacademia.net emma.csemiczky@openacademia.net
Web: http://www.openacademia.net www.openacademia.net
Från: Nate Wright notifications@github.com Skickat: den 6 januari 2021 18:03 Till: pkp/pkp-lib pkp-lib@noreply.github.com Kopia: openacademia emma.csemiczky@openacademia.net; Mention mention@noreply.github.com Ämne: [pkp/pkp-lib] Restrict usage/abuse of new notify feature (#6536)
OJS/OMP/OPS 3.3 will introduce a new feature that allows managers to send an email to all users with a role https://github.com/pkp/pkp-lib/issues/4017 . The manager can select the user roles they want to email, compose an email, and have it sent to all users.
This feature can cause problems if not used properly. Sending some kinds of unsolicited emails to certain users may violate local anti-spam or privacy laws. And if recipients flag these emails as spam -- or if emails are repeatedly bounced back from incorrect addresses -- the email server's IP address may get put on a blacklist, which will cause all of the emails sent by the system to be blocked.
This issue is to discuss what tools and settings publishers and hosting providers need in order to reduce or prevent unwanted use of this feature. In particular, I am hoping to receive feedback from PKP's hosting services as well as community partners involved in hosting and service delivery.
The following are some ideas:
Enable/disable per journal/press/preprint server
A setting in the admin area would permit the feature to be enabled/disabled for each journal/press/preprint server. This would provide service providers with a way to offer this feature to trusted managers on request without opening it up to every manager in the system.
Enable/disable per role
A setting in the admin area that allows an admin to restrict which roles can be sent an email. An admin might, for example, want to allow the feature to be used to send emails to authors, assistants and editors but not reviewers and readers (who probably have not opted in). This would limit the scope of damage that could be caused by sending emails to people with only a loose connection to the journal/press/preprint server.
This setting could have a site-wide setting and a context setting, so any journal/press/preprint server that did not have a specific setting would fall back to the site-wide setting.
Customizable warning
An admin setting to write a custom warning, that would appear in the confirmation prompt before an email is sent, in which they identify the legal hazards of an email or outline under what conditions an email should or should not be sent.
User unsubscribe
Users should be able to unsubscribe from these emails. However, it's not yet clear how we could make that work sensibly. Since the emails that are being sent could be about anything, there's no way to indicate to the user what they are unsubscribing from. For example, a user might want to unsubscribe from generic announcement emails but should still receive an email a manager sends asking authors to add their ORCID.
In order to do this, we probably need to come up with a taxonomy of message types, require the manager to choose one of these types when sending an email, and allow the user to unsubscribe from them. I'm thinking of types like "Occasional Announcements and Updates", "Editorial Requirements", etc. Any others?
We won't have time to do all of them before 3.3 is released. Which settings would be the most useful? Do you have any other ideas for tools/settings that service providers need?
cc @mfelczak https://github.com/mfelczak @marcbria https://github.com/marcbria @mtub https://github.com/mtub @withanage https://github.com/withanage @ajnyga https://github.com/ajnyga @alexxxmendonca https://github.com/alexxxmendonca @openacademia https://github.com/openacademia
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pkp/pkp-lib/issues/6536 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKNX5MINZLX32HVYVTAG443SYSJUJANCNFSM4VXZWK5A .
NateWr
commented
3 years ago Thanks @openacademia, that's really helpful. I think your discussion of the need to manage/curate the reviewer pool is probably worth documenting in a separate feature request. I can imagine some dedicated tools to help with this and I can see how this list is one of the most valuable assets of a journal.
And yes, in 3.2.x users can opt out of announcement and issue email notifications. I'm not sure if it was introduced right with 3.2 or in a later 3.2.x, but it is now possible to unsubscribe and an unsubscribe link is included in the emails.
ctgraham
commented
3 years ago Feedback from the ULS:
The absence of this feature has come up repeatedly in the upgrades to 3.x, and reimplementation is welcome.
An additional suggestion: On a new user registration, or on enabling this feature, present a message or email describing the notifications/consent and providing an opt-in/opt-out method. There was a flurry of such emails from multiple services immediately after GDPR was effected.
NateWr
commented
3 years ago Thanks @ctgraham!
perhaps the most maintainable and accurate taxonomy would be by role: "Messages to all Readers", "Messages to all Reviewers", etc.
This didn't sound right to me at first but the more I think about it the more it makes sense. Thinking about the use-cases described, it seems like there is a real distinction in how this feature might be used based on role:
Are there other use cases I've missed? One case that I've often thought of is following up with authors to ask them to authenticate their ORCID or add an ORCID. But I think this should probably be a one-off email triggered by the ORCID plugin rather than something that goes through the Notify feature.
ctgraham
commented
3 years ago Concur that the reviewers email might be best tied to a larger stats and recommitment process. (That is one of our recent use-cases.)
jnugent
commented
3 years ago Hi @NateWr, I know that there has been lots of other work done on the bulk email part of OJS, most notably with both the progress bar and the sanity check pop-up before sending email. On the server side, one of our biggest problems with many emails going out like this is that we often hit the queue limit on our server when a large journal sends thousands of emails at once. I don't know if rate limiting any of this is possible (e.g. an admin/site-wide setting to limit to "X bulk emails per hour") or to off load bulk email sending into a scheduled task that can notify the sender when the task is finished. The effect of this is that other journals on the server, who are trying to send their own emails, end up filing tickets claiming that their emails aren't being delivered.
Spam and blacklists have been discussed with respect to too many emails going out but Google will also punish you if you send too many emails at once. It's slightly vague, but there are also limits on sending email through gmail per day, for example. I think that's a 500 email cap.
NateWr
commented
3 years ago we often hit the queue limit on our server when a large journal sends thousands of emails at once. I don't know if rate limiting any of this is possible (e.g. an admin/site-wide setting to limit to "X bulk emails per hour")
I don't think we have any facility at the moment for limiting the number of emails that are queued up. I guess in order to do this we would need some way to communicate with the email server to know when the queue reaches a limit, right?
Thinking about the bulk emails per hour thing, I would think that we'd need some way to track emails sent, which isn't really a consideration the job processing system that we've implemented. I'm not sure whether this is best handled by the application or the server. My understanding is that on the PHP side we simply send the request off to the mail server. Is there any way on the mail server to receive a request but hold on to it? Or is there a way to intercept these requests to the mail server and track their frequency that way?
jnugent
commented
3 years ago If it was possible to dump a request for a mailout into a task and then have a server-side scheduled task send those mails out at an administrator-setting rate, that would be nice. For instance, if we had an outgoing mail queue that can hold 50 email at a time, the scheduled task could grab a bunch of outgoing email, send 50 of them, pause for a few minutes, and then when the task runs again, grab another 50.
But I agree that a lot of this is better handled elsewhere. It's been my recommendation to many hosting clients to implement their mailouts in a third party tool like SendGrid or MailChimp, with a sign up form or link in a sidebar block on the installation. Those applications handle bulk email very well, rate limit it, and also look better.
Bonus points if there were a set of plugins that could communicate directly with those third party APIs.
NateWr
commented
3 years ago For instance, if we had an outgoing mail queue that can hold 50 email at a time, the scheduled task could grab a bunch of outgoing email, send 50 of them, pause for a few minutes, and then when the task runs again, grab another 50.
We do something a little bit like this with the new job queue. When the notify feature is used, a bunch of jobs are queued, each sending 100 emails. Then these jobs are processed sequentially, so it doesn't pile up long-running requests on the server. And in particular, if 5 journals in one instance of OJS hit send on large emails at once, it won't try to process all 5 at the same time. They'll get queued up.
However, this only takes account of how many emails are being processed in a single server request. It doesn't say whether the emails have been sent and cleared off by the email server or if they are starting to back up there. This is where it seems like we'd need some communication from the email server itself, right? If one email server is sending emails from more than one instance of OJS, then rate limiting in the application wouldn't suffice.
jnugent
commented
3 years ago For rate limiting, a lot of this just comes down to systems administrator best practices when configuring and allocating resources. The size of the mail queue on the server can be adjusted, just like any other systems parameter. We may not need to specifically communicate with the mail server if we can set reasonable limits and then do our own debugging if we know email aren't being delivered. I don't expect the application to even have access to the sorts of system-level logs or information that an administrator would, especially if were to remain as platform agnostic as it is now. That process is essentially what we do now anyway. If there was a way to limit the time between each of those 100 email batches, that would be quite nice. Doing that probably means pushing email sending into the background though.
NateWr
commented
3 years ago Thanks everyone. Based on the feedback I'm going to begin working on some quick changes we can push out with 3.3 and then file some issues for additional work at a later date. Please review and let me know if I've got anything wrong.
For 3.3:
For the future:
marcbria
commented
3 years ago Sounds like a good plan too me, but let me a few more words about:
The feature will be off by default and an admin will have to enable it for each journal/press/preprint server.
How are you planning to enable/disable this? I suggested it to be in the config.inc.php to be sure no journalmanager or OJS admin can enable it (as far as it will have impact in the infrastructure performance, I think it need to be enabled by the sysAdmins). Think that in a singleOJS installation let OJS-admin (or journalmanager) users enable it via GUI will work fine, but I'm also thinking in multiOJS installations where they have an "ojs per journal" and can login as journalmanager (even admin) because they own a complete OJS instance.
There will be no customizable warning before sending emails, because this wasn't thought to be very effective.
Not sure about this (even the message will be ignored most of the times, but advice when an activity is intensive with the resources... sounds like a good idea), but looks like I'm alone with my doubts so let's go as you said.
Cheers, m.
NateWr
commented
3 years ago I suggested it to be in the config.inc.php to be sure no journalmanager or OJS admin can enable it
It will be in the admin area, so journal managers can not access it. Only the admin account can. We are trying to reduce config options in order to focus on supporting mutli-tenant installations.
If you have journal managers who are given admin access, I'd recommend rethinking that assignment or considering writing a plugin to lock-down critical settings (I can show you how if/when you need).
marcbria
commented
3 years ago We are trying to reduce config options in order to focus on supporting mutli-tenant installations.
Ok. I know multi-tenant was the most extended choice but I didn't know it was also the preference in PKP hosting. Anyway, it's also a good idea reduce config variables to make it easy to config OJS from code (ie: CI)
If you have journal managers who are given admin access, I'd recommend rethinking that assignment or considering writing a plugin to lock-down critical settings (I can show you how if/when you need).
I did it sooo long ago, but it need to be updated to 3.x: https://github.com/marcbria/adminLocker But in some months from now I take you at your word because I never made a plugin for ojs 3 (yet). ;-)
So, if there are no more scenarios to justify config in file as I suggested, I'm also ok with the proposal.
asmecher
commented
3 years ago On email limits, there are options for Laravel-based middleware to introduce this kind of functionality: https://github.com/spatie/laravel-rate-limited-job-middleware The config file could include a maximum-emails-per-hour parameter, and the middleware could limit things to just that. It would require all email sending to go through the queue toolset, though. (Another complex feature that gets magically easier when using queues to send emails: allowing an edit window of e.g. 60 seconds before a message goes out, for the inevitable typo discovery.)
NateWr
commented
3 years ago I took a stab at the unsubscribe features but have hit a blocker. We won't be able to implement a reasonable unsubscribe option until the notification subscription settings are refactored, which means it won't get into 3.3. I've filed an issue and scheduled it for 3.3.1 -- although I think that milestone is already overloaded and this may present a number of unforeseen complications.
asmecher
commented
3 years ago :+1: -- we'll have to have a sober review of the list for 3.3.1 once 3.3 is out.
NateWr
commented
3 years ago The following PRs change the notify feature to off-by-default and add admin settings to enable it by journal and to disable sending to user groups within a journal.
PRs: https://github.com/pkp/pkp-lib/pull/6628 https://github.com/pkp/ojs/pull/2999 https://github.com/pkp/omp/pull/911 https://github.com/pkp/ops/pull/111
Enable the notify feature for each journal/press/server from the site settings.
For each journal/press/server, it's possible for the admin to disable sending to specific roles.
cc @amandastevens @kaitlinnewson This may effect documentation for 3.3.
NateWr
commented
3 years ago Thanks everyone. The admin settings have been merged and issues have been filed for some of the other things that were raised here.
OJS/OMP/OPS 3.3 will introduce a new feature that allows managers to send an email to all users with a role. The manager can select the user roles they want to email, compose an email, and have it sent to all users.
This feature can cause problems if not used properly. Sending some kinds of unsolicited emails to certain users may violate local anti-spam or privacy laws. And if recipients flag these emails as spam -- or if emails are repeatedly bounced back from incorrect addresses -- the email server's IP address may get put on a blacklist, which will cause all of the emails sent by the system to be blocked.
This issue is to discuss what tools and settings publishers and hosting providers need in order to reduce or prevent unwanted use of this feature. In particular, I am hoping to receive feedback from PKP's hosting services as well as community partners involved in hosting and service delivery.
The following are some ideas:
Enable/disable per journal/press/preprint server
A setting in the admin area would permit the feature to be enabled/disabled for each journal/press/preprint server. This would provide service providers with a way to offer this feature to trusted managers on request without opening it up to every manager in the system.
Enable/disable per role
A setting in the admin area that allows an admin to restrict which roles can be sent an email. An admin might, for example, want to allow the feature to be used to send emails to authors, assistants and editors but not reviewers and readers (who probably have not opted in). This would limit the scope of damage that could be caused by sending emails to people with only a loose connection to the journal/press/preprint server.
This setting could have a site-wide setting and a context setting, so any journal/press/preprint server that did not have a specific setting would fall back to the site-wide setting.
Customizable warning
An admin setting to write a custom warning, that would appear in the confirmation prompt before an email is sent, in which they identify the legal hazards of an email or outline under what conditions an email should or should not be sent.
User unsubscribe
Users should be able to unsubscribe from these emails. However, it's not yet clear how we could make that work sensibly. Since the emails that are being sent could be about anything, there's no way to indicate to the user what they are unsubscribing from. For example, a user might want to unsubscribe from generic announcement emails but should still receive an email a manager sends asking authors to add their ORCID.
In order to do this, we probably need to come up with a taxonomy of message types, require the manager to choose one of these types when sending an email, and allow the user to unsubscribe from them. I'm thinking of types like "Occasional Announcements and Updates", "Editorial Requirements", etc. Any others?
We won't have time to do all of them before 3.3 is released. Which settings would be the most useful? Do you have any other ideas for tools/settings that service providers need?
cc @mfelczak @marcbria @mtub @withanage @ajnyga @alexxxmendonca @openacademia @ctgraham @PeterFordUP