OJS 3.5.0.4 - Unable to save "Reviewing Interests" in Create Reviewer Form

Software Support
1

Hello everyone,

We are running a brand-new journal using OJS 3.5.0.4. We are encountering a persistent issue when trying to add/edit reviewers.

When we attempt to add a reviewer or update their profile to include “Reviewing Interests,” the system returns the following error: “You must select at least one reviewing interest in the ‘Roles’ tab before you can access the system.”

Here is the current situation:

  • We are using the Default theme.

  • The “Reviewing Interests” field seems to fail to trigger the tagging/array creation properly. When we input interests and click “Save,” the data is not persisted, and the system prompts the error as if the field were empty.

  • I have inspected the createReviewerForm.tpl file and attempted to modify the fbvElement parameters, but the issue remains unresolved.

  • I have already tried clearing data caches and template caches via the Administration dashboard, but it did not help.

We are unable to bypass this validation error, even though all other mandatory fields are correctly filled. As the journal is new, we are looking for a definitive, easy fix to this validation block.

Has anyone encountered this specific issue in version 3.5.0.4, or is there a known workaround to disable the mandatory requirement for this specific field?

Any guidance or code snippets to fix this form validation would be greatly appreciated.

Thank you in advance for your support.

2

We’re seeing the exact same behavior on OJS 3.5.0-5, so this isn’t isolated to 3.5.0.4. In our case it surfaced through the “Selection of Reviewing Interests” plugin (generic/selectionOfReviewingInterests), which redirects/blocks any user with the Reviewer role whenever User::getInterestString() returns empty — but the underlying persistence problem is the same one you’re describing, and it looks like it sits in OJS core rather than in that plugin.

Root cause we found:

Tracing the save path: RolesForm::execute() calls Repo::userInterest()->setInterestsForUser($user, $this->getData('interests')), which lives in lib/pkp/classes/user/interest/Repository.php. That method deletes the user’s existing rows in user_interests, then rebuilds them from the submitted interests value via ControlledVocabEntry.

In our case, after submitting interests and getting the “saved” confirmation, user_interests came back completely empty for the affected user:

sql

SELECT * FROM user_interests WHERE user_id = <id>;
-- 0 rows

So the form believes the save succeeded, but nothing is actually persisted — which then makes any downstream check on getInterestString() (whether from core or from a plugin like ours) fail indefinitely, even though the user re-enters the same interests every time.

We haven’t yet isolated whether the break is in how RolesForm reads interests from the request, in the ControlledVocabEntry create/match logic, or somewhere in how the tagit field serializes on submit — but the fact that two different installs (3.5.0.4 and 3.5.0-5), through two different forms (Create Reviewer Form and the profile Roles tab), hit the identical dead end strongly suggests this is a core regression in PKP\user\interest\Repository::setInterestsForUser() rather than a template/theme issue.

Workaround for anyone blocked right now: if the “Selection of Reviewing Interests” plugin is what’s enforcing the block for you (redirect/error on login when interests are empty), disabling that plugin removes the hard lock so users can access the system again — it doesn’t fix the underlying persistence bug, but it stops it from being a full access blocker.

Happy to share more detail (schema, query traces) if that helps narrow it down. This seems worth flagging for the dev team given it affects reviewer onboarding across versions.

(Diagnosis assisted by AI/Claude, based on direct debugging of our production database and codebase.)