Hi all,
Thanks for the feedback, @geniusdesign – a couple additional notes on top of what @jonasraoni said…
USER MANAGEMENT (MOST CRITICAL):
We’ve been talking about the GDPR changes to user management both internally and with users for quite a while, and I’m aware it’s going to be frustrating for some journal managers/editors who are used to taking on user management for users who have trouble. So I’ll take a few paragraphs to talk about this (and probably link to it from future threads
). There are a few existing threads about this in the forum already:
While GDPR is European-centric legislation, we are seeing it directly inspire legislation in other areas, and expect it will become the norm anywhere that decides to make it the law. So even if you’re in a region without GDPR-style legislation, it’s likely coming. It’s good legislation and well informed about technological limits and possibilities, which I have to say is pretty rare.
Even if you’re not and never will be in a region with this kind of legislation, pretty much every software vendor with a global audience will adopt a GDPR-compatible toolset, and PKP software is no exception. That means, I think, that user expectations will gradually align. Supporting both GDPR and non-GDPR “modes” represents a lot of extra coding and frankly we just don’t have the resources to code, test and maintain separate implementations for separate regions.
When we discussed GDPR and privacy in general at our last few sprints, the culture of librarianship came up repeatedly, and I think it’s an important piece of how this change will land. Librarians have a culture of service, and their response to a scholar’s request of “can you change my password?” is likely to be “sure, let’s walk you through that.” The same scholar would never expect Google to help them the same way with a lost gmail password. In this case scholars expect journal managers to have power over their accounts that is contrary to GDPR legislation, and unfortunately it’s the scholars who will have to change.
One quick note, so that this all doesn’t sound like bad news: The administrator still has the power to work more directly with user accounts. This is not contrary to GDPR.
EMAIL SENDING
This is related to the GDPR discussion. A frequent underlying problem that leads to journal managers being asked to perform actions on behalf of lost users is trouble with email delivery. I see that this is also listed with your feedback, and I’m aware that there are several related issues we’d like to tackle in the near future that might help:
- [Email] | Invitations, Notifications and more - DMARC compliant from headers not correctly respected · Issue #11582 · pkp/pkp-lib · GitHub
- [Emails] | Cannot force the from address seemingly · Issue #11685 · pkp/pkp-lib · GitHub
OJS is fundamentally an email-based workflow application, so any deployment that regularly loses emails will be a problem. DMARC and related configuration are unfortunately complicated, and everyone’s hosting service is a little different, and the big email players (primarily Google and Microsoft) make it hard for 3rd party services to participate – so some time and effort will be necessary to get email to send reliably. As we adopt invitations more broadly through the system, this will only get more important.
Regards,
Alec Smecher
Public Knowledge Project Team