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?
SELECT *
FROM [review_assignments]
WHERE
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…
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.
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.
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?