In OJS 2.x is possible to send an e-mail to multiple users in a particular roles from the enrolled users page or by using the “notify users” function. However, this functionality is not enabled/present in OJS3. Would be feasible consider it for future releases @asmecher @bozana ?
See discussion here: https://github.com/pkp/pkp-lib/issues/2561#issuecomment-307073836
And here is my argument against: https://github.com/pkp/pkp-lib/issues/2561#issuecomment-308110455 :)
A PKP|PS hosted client would like to be able to send out the new issue published notification to Readers only, as was the behaviour of OJS 2. Being able to select which roles receive a notification, as suggested by @ajnyga, would be ideal.
Another +1 for PS.
This came up with another PKP|PS client and they had an interesting use case that I want to note. They want to send a message to all of their reviewers to ask them to update their accounts with reviewing interests and to check who is still active. The only way they can do this in OJS is to email each reviewer individually. Or they can do it in bulk outside of OJS by exporting all reviewers from the database and sending them an email.
As I was discussing the email features with the client they said, "To communicate with users you can either send an email to one individual or you can make a public announcement to everyone. There should be something in between."
Regarding the mechanics of sending batches of notifications, see also: https://github.com/pkp/pkp-lib/issues/4622
The following PRs draw on work done for #4622 in order to add support for sending an email to all users in a role. It draws on work done for #4622.
I suspect we'll still have a lot of questions that need to be answered about this feature -- particularly GDPR concerns and the threat to server's delivery rates.
PRs:
https://github.com/pkp/pkp-lib/pull/6374
https://github.com/pkp/ui-library/pull/129
https://github.com/pkp/ojs/pull/2917
https://github.com/pkp/omp/pull/881
https://github.com/pkp/ops/pull/83
@asmecher I'm getting an error running the unit tests that looks like an issue with the __() function getting moved:
Fatal error: Cannot redeclare __() (previously declared in /home/travis/build/pkp/ojs/lib/pkp/lib/vendor/laravel-zero/foundation/src/Illuminate/Foundation/helpers.php:893) in /home/travis/build/pkp/ojs/lib/pkp/includes/functions.inc.php on line 370
https://travis-ci.com/github/pkp/ojs/jobs/447619583#L3374
It looks like this is related to the laravel-zero/foundation package. I tried removing it but it looks like it is a dependency for the queue stuff. Any ideas?
an issue with the __() function getting moved
Moving the __ function from PKPLocale.inc.php to functions.inc.php fixed that in OJS proper (by getting our __ in first, since the laravel-zero package wraps a function_exists check around it) but I'll check what's going on with the tests.
(This appears to be more or less exactly https://github.com/composer/composer/issues/6768; still working on it)
@NateWr, this should do it: https://github.com/NateWr/pkp-lib/pull/9
@NateWr, re: your previous comment...
the threat to server's delivery rates.
...I don't suggest we solve that yet, but putting email delivery behind the Laravel queue toolset is a big step towards it anyway, as queues support middleware including rate limiting: https://laravel.com/docs/8.x/queues#rate-limiting
(Related forum comment: https://forum.pkp.sfu.ca/t/email-configuration/51594)
It is interesting that bulk messages can be sent using a different SMTP / Sender configuration than transactional messages.
And that come with the option of "one-click unsubscribe" as exemplified in:
https://support.google.com/mail/answer/81126?hl=en
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://your-company-net/unsubscribe/example>
When a user unsubscribes using one-click, you receive this POST request:
"POST /unsubscribe/example HTTP/1.1
Host: your-company.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-Click"
Thanks for the assist, Alec. All merged!
@diegoabadan, unsubscribe poses some challenges with this feature. Since it can be used to send so many things (everything from mission-critical messages for section editors to general promotional content), it's not clear what the user would be unsubscribing from. This is part of the discussion that we probably need to have about this feature. Hopefully, the period before release will give us an opportunity to figure that part out.
@NateWr, his mix of transactional messages, such as password recovery and an invitation to review an article, with messages to a greater number of recipients and with different content also affects the deliverability of OJS messages, especially to larger installations.
In this sense, being able to separate transactional messages from others would be an interesting step, following the recommendations of major providers.
Thanks for the feedback and I hope to be able to collaborate with future discussions.