OJS 3.2 fatal error with Reviewer's report

Describe the issue or problem
On OJS 3.2.1-4, when I try to get the reviewer’s report (in report generator) I get the following error:

PHP Fatal error: Uncaught Error: Call to a member function getId() on null in /var/www/html/lib/pkp/classes/user/InterestManager.inc.php:52

Stack trace:\n#0 /var/www/html/lib/pkp/classes/user/InterestManager.inc.php(73):
#1 /var/www/html/plugins/reports/reviewReport/ReviewReportDAO.inc.php(113): InterestManager->getInterestsString(NULL)
#2 /var/www/html/plugins/reports/reviewReport/ReviewReportPlugin.inc.php(66): ReviewReportDAO->getReviewReport(1)
#3 /var/www/html/lib/pkp/pages/management/PKPToolsHandler.inc.php(155): ReviewReportPlugin->display(Array, Object(Request))
#4 /var/www/html/lib/pkp/pages/management/PKPToolsHandler.inc.php(58): PKPToolsHandler->report(Array, Object(Request))
#5 /var/www/html/lib/pkp/classes/core/PKPRouter.inc.php(391): PKPToolsHandler->tools(Array, Object(Request))
#6 /var/www/html/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)
#7 /var/www/html/lib/pkp/classes/core/Dispat in /var/www/html/lib/pkp/classes/user/InterestManager.inc.php on line 52, referer: https://ensciencias.uab.cat/management/tools

Steps I took leading up to the issue
For example:

  1. Go to ‘Statistics > Report Generator’
  2. Click on ‘Review Report’
  3. You will get a WSOD.

What application are you using?
OJS 3.2.1-4

Additional information

  • As error only happens in one of the 50 independent journals I think the issue is related with the DB content (journal started in 2.x).
  • As the error refers InterestManager, this is the table to start digging.
  • As it happens to us in past with other data, my guess it could be related with inconsistent multilang information in the interest manager table.

I will debug it to discover the exact user where it crash and report back just in case it could be cleared during the upgrade pre-scripts.

1 Like

I added some print_r in the code to trace the issue (InterestManager.inc.php lines 52 and 73) and looks like the $user variable is empty.

Any idea how is this possible or how to keep tracing it?

Hi @marc

This sounds like there’s a review associated with a user that is no longer in the database. At some point a userId was fetched, the UserDAO tried to create a user with it, ended up with null instead, and passed that on to the Interests Manager.

Can you see if you’ve any review assignments that have reviewer_ids that do not point to valid users?


1 Like

Thanks a lot Jason,

You nailed it! :star_struck:

I run this query to find the missing references:

FROM [review_assignments]
    reviewer_id NOT IN
    (SELECT user_id
    FROM users);

And this trows two rows pointing to reviewer_id… zero?
I replaced them to admin (user 1) and I could run the report without any trouble.

I can’t imagine why those two rows where pointing to an nonexistent user.
This journal started directly in ojs 2.x in our service (not coming other’s hands) and all upgrades were made by ojs itself.

Did you found this problem before?
I’m asking to discover if make sense to add this check to the pre-fight upgrade scripts…

Take care,

Hi @marc

I’m not really surprised that you had review assignments with a review_id of 0 if the journal began life in OJS2. OJS2 just wasn’t as robust with respect to data integrity and there may have been an old bit of code that casted something that wasn’t an integer using int or something, which would have returned a 0.

The other thing we encounter fairly often during upgrades are review_assignments with null review rounds. We find going directly from OJS2 to stable-3_2_1 (not the release of 3.2.1-4) is pretty robust. Then we can go to 3.3.


1 Like

Yes… I know. :slight_smile:

Our internal rule is “if the change it’s only the last number” (release/security) I can apply it without asking our journals about a new functional test… but I was unsure about what would happen if we jump from 3.2.1-4 > stable-3_2_1, so I stop it there and I just apply specific security patches.

Now we are planning going to 3.3-LTS in next Q1 so I’m trying to save an extra step because it will require a deep testing and I can’t ask our journals for more than one functional test a year.

If it’s ok to you, I will publish the issue in github, so dev team could decide if we need to include this in the pre-upgrade checks.

Do you agree?

Hi @marc

To be honest, I am no longer completely sure about what the procedure is for issues on github, since I believe that now we create issues on Github if there is someone “assigned” to the work involved (I think?). Maybe ask in the Development channel on MM?


1 Like

Thanks a lot Jason.
I will ask there. :ok_hand: