Feedbacks from 3.5 version using in production

Software Support
,
1

Hello everyone,

We are very excited about the new version of OJS. The new article view is simply excellent. Like with any new version, there are adjustments to be made, and I want to leave my contribution here.

We have updated from OJS version 3.4.0.8 to 3.5.0.1 and have observed some changes in the new version that have been causing significant difficulty for our users.

PHP Version: 8.3

USER MANAGEMENT (MOST CRITICAL):

  • It is no longer possible for the editor to create new users, only to invite them to a role. With many researchers having difficulty using web systems, and specifically OJS, it is crucial that the editor is able to create new users directly.

  • It’s not possible to edit registered users’ profiles. Although there is an “Edit” link ([…]), the “edit screen” only allows assigning roles in the journal. This complicates management for the journal editor, who cannot edit user data, such as their email or login password when needed.

  • There is no option to filter the user list by role. The ability to filter users by their roles is very important for quickly viewing all users assigned to a specific role (such as Section Editors or Guest Editors, for example).

LANGUAGE MANAGEMENT:

  • The new OJS dynamically loads the interface language based on the browser’s settings, no longer respecting the “Primary locale” option in the website settings. It would be beneficial to have an option to choose between this dynamic loading and the default language defined in the website settings.

REVIEW FORMS:

  • Due to the new language behavior, review forms are loaded in the user’s browser language. However, fields that use <option> elements (radio buttons, select menus, and checkboxes) appear blank if the labels for that specific language are not filled in. It would be better if these fields defaulted to any available language instead of showing empty options.

EMAIL SENDING:

  • I am using an SMTP configuration with AWS/SES credentials. Some emails are sent correctly; in general, all manual actions performed in the system (e.g., editorial decisions, direct messages to users, discussions) work fine. However, some automated emails are not being delivered. The most critical one is the password recovery email. I suspect that different system functionalities might be using different email-sending methods, as it doesn’t make sense for some emails to be sent correctly while others fail.
    (I performed this password recovery test on another 3.5 installation that was also upgraded from a 3.4 version and observed the same behavior).

ERROR LOGS:

PHP Deprecated:  Using ${var} in strings is deprecated, use {$var} instead in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/StyleSheet.php on line 52
PHP Deprecated:  Creation of dynamic property Seboettg\CiteProc\Root\Info::$title-short is deprecated in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/Root/Info.php on line 62
PHP Deprecated:  Creation of dynamic property Seboettg\CiteProc\Root\Info::$category is deprecated in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/Root/Info.php on line 62
PHP Deprecated:  Creation of dynamic property Seboettg\CiteProc\Root\Info::$summary is deprecated in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/Root/Info.php on line 62
PHP Deprecated:  Creation of dynamic property Seboettg\CiteProc\Root\Info::$updated is deprecated in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/Root/Info.php on line 62
PHP Deprecated:  Creation of dynamic property Seboettg\CiteProc\Root\Info::$rights is deprecated in /ojs_root/plugins/generic/citationStyleLanguage/lib/vendor/seboettg/citeproc-php/src/Root/Info.php on line 62
PHP Deprecated:  htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /ojs_root/plugins/generic/googleScholar/GoogleScholarPlugin.php on line 120
1 Like
2

Hi!

Just giving an initial/short feedback, perhaps someone else will complement.

USER MANAGEMENT (MOST CRITICAL)

AFAICR these changes were introduced due to GDPR requirements.

As a user, I definitely agree these changes are unexpected, and given that every country might have a different set of laws, I’d say it makes sense to have a “ Comply with GDPR” together with a list of changes that will occur if this option is enabled.

LANGUAGE MANAGEMENT

That’s right, if the user has a language preference in the browser that matches one of the languages which are enabled in the application, it will be used. I think it’s feasible to include the option you’ve mentioned as a workaround, but the long-term fix is to get everything translated properly and provide the best experience for the user.

REVIEW FORMS

I think this requires an internal review and improvements :ok_hand:

For example, I saw it’s not possible to edit a review form which has been used already (I’ve checked on 3.3, but I guess it’s the same on newer versions), but it probably should, at least partially or with warnings (e.g. “someone has filled this input, if you remove, the old information will be lost”, “if you update the description, the previous answers may not make sense”, …).

About the missing options, as a user, I also agree it’s better to see text in a random language (the best match can be retrieved by locale similarity, as es_ES kind of matches es_AR, and fallback to the primary language or anything else that’s filled), than nothing at all. I’ve also discussed internally to enable the default translation plugin by default, to also avoid a similar type of problem (when you see ##text-missing-translation## on the UI).

EMAIL SENDING

That’s curious… Did you check if they were forwarded to the AWS service? Aren’t there error messages on the log? It could be a bug, so it’s needed to also review internally.

ERROR LOGS:

Only the last item can be fixed by us, the others belong to an external library, where we may just contribute with improvements.

Best,
Jonas Raoni

3

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 :smile:). 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:

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

4

Hello @jonasraoni and @asmecher,

Thank you very much for your detailed reply! Indeed, the adjustments to OJS to comply with GDPR requirements make perfect sense. Unfortunately, in practice, the system’s configuration in many places reveals a poor habit — removing responsibility from the competent users who should be making key decisions in the system.

The reality is that this can be a major barrier to adopting the new version if we consider the technical limitations — whether from journal editors/managers or from the professionals who support them — regarding proper email configuration (DMARC, DKIM, SPF, etc.). As @asmecher mentioned, OJS is entirely built around a workflow that uses email as a key tool.

LANGUAGE MANAGEMENT

If the intention is for the new version to give users greater control over their data and their experience with the system, the current configuration makes sense but will require more effort from editorial teams to ensure complete translation of all information.

Is the absence of the defaultTranslation plugin as a native plugin or in the plugin gallery related to this? Its absence is strongly felt in several interface elements.

REVIEW FORMS

Editing active forms has indeed not been allowed since version 3.x (I can’t recall if this was already the case in version 2). It would be quite useful to allow editing, even with limitations, since sometimes subtle errors need to be fixed, and this currently requires duplicating the form, potentially resulting in multiple versions of evaluation forms. This is because as soon as a single review is assigned with that form, editing is blocked.

If a review form in a journal with three enabled languages (as in the OJS 3.5 case I tested) is created using only one language, the question labels are displayed in the available language. The same does not happen for the options. It would be interesting if options worked the same way.

EMAIL SENDING

“That’s curious… Did you check if they were forwarded to the AWS service? Aren’t there error messages on the log? It could be a bug, so it’s needed to also review internally.”

The messages did not reach AWS, and no error logs were generated. I was left completely in the dark when trying to debug this behavior in specific cases.

The infrastructure for this installation is as follows:

  • VPS server hosting OJS;
  • Shared server hosting the email accounts (it used to host the journal itself, but we migrated to a VPS because upgrading from 3.4 to 3.5 requires long database connections, which could exceed the limits of shared hosting);
  • OJS configured to use AWS Simple Email Service, with domain and email addresses properly set up and validated;
  • Journal’s domain configured with the shared server’s nameservers (legacy);
  • DKIM, DMARC, and SPF fully validated. The test via mail-tester.com returned a score of 9.5/10 (small deductions in SpamAssassin due to test content) for a message sent manually from OJS via the user manager. The password reset email, however, did not reach the mail-tester inbox.

@asmecher

From the issues you shared, and if I understood correctly, in version 3.5 the force_dmarc_compliant_from parameter is not currently working, correct? Could this be related to the email problem I reported?

EMAIL SENDING – NEW CASE

One notification that versions ≤3.4 used to send was when a reviewer accepted an invitation to review. From what I observed in the log of a submission in OJS 3.5, this notification was only recorded but not actually sent by email. The email was sent only when the review was submitted.

Would this be considered a bug, a change in this version, or a possible consequence of the email issue I reported?

5

@jonasraoni and @asmecher On the 3.5 Demo site, if a user wants to update their email address, they make the change to their profile, then save the change. OJS responds with “You have requested a change of your email to “firstname.lastname121@mynewinstitution.edu”. We have sent you an email with directions on how to validate the changed email.” Is this email being sent to the old email address? In many cases, by the time the user realizes that their OJS email address is from a former institution, the account at that institution has been deactivated/deleted so the email will not be delivered and the change will not be able to be validated.

If this is the case, how can the email address be updated? Should the user create a new profile with their new address and then the editors merge the two profiles, keeping the one with the new email address? Is there another way?

Best,

Marianne Reed @mreedks

1 Like
6

Hi @mreedks,

Not to worry; the email to be validated is the new address, not the old one.

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like
7

Thanks, @asmecher! I had just had an experience with another web site where the confirmation went to my old email address (“Did you really request this email change to newaddress@gmail.com?”) so I thought that I should ask.

– Marianne

1 Like
8

This topic was automatically closed after 8 days. New replies are no longer allowed.