[OJS 3.3.0.8] Review report missing articles in list

Hello anyone,

Description of issue or problem I’m having:
In our journal we provide a list of reviewers that acted during the period an issue is being produced. We use the review report in OJS to filter articles with any review in a specific period. However, in 3.3.0.8 (we’re unsure if this is a current bug or if it’s preexisting to older versions!), we noticed an article is missing from the list. Now, we cannot trust the only tool we have to provide such information.
The article we tested has been rejected, has all reviews and editorial decision in the editorial workflow, with the e-mail sent to authors, but it’s not present in the review report.

Steps I took leading up to the issue:
I just downloaded the report from Acesso | Ciência da Informação
image

Then, imported into Google Sheets, which works better than Excel, but in either spreadsheet application software, the submission ID 5238 is not present.

What I tried to resolve the issue:
There’s nothing I can do right now.
We could provide temporary editorial access to our OJS install, send the CSV or provide access to our spreadsheet for analysis.

Application Version - e.g., OJS 3.1.2:
OJS 3.3.0.8

Additional information, such as screenshots and error log messages if applicable:

Google Sheets search on Submisison ID column - ID 5238 not found
image

Excel search - ID 5238 not found
image

Hello anyone,

This seems to be an important bug, as we just tested another reviewers report and another review is missing from the list.

This needs to be fixed ASAP as we depend on this report for editorial control.
Unless there’s another way to export information on reviewer activity we are unaware of.

Hi @ramon,

Thanks for flagging this. To help look into this further, could you answer a few questions about your specific case?

Was this a journal that was recently upgraded and did these issues only start after the upgrade was complete?

How many submissions have you noticed are missing from the report? You specifically mention submission ID 5238, but are there others?

If this limited to this or a few submissions, you could look at the entries in the database to see if there may be some reason those submissions are missing and not others. Within the review reports plugin, one of the primary database queries is below. You could try exploring that and see why it would not be appearing. It’s possible something could have gotten lost or changed over the course of upgrades.

Here is the query:

SELECT	r.stage_id AS stage_id,
				r.review_id as review_id,
				r.round AS round,
				COALESCE(asl.setting_value, aspl.setting_value) AS submission,
				a.submission_id AS submission_id,
				u.user_id AS reviewer_id,
				u.username AS reviewer,
				COALESCE(ugl.setting_value, ugpl.setting_value) AS user_given,
			CASE WHEN ugl.setting_value <> '' THEN ufl.setting_value ELSE ufpl.setting_value END AS user_family,
				u.email AS email,
				u.country AS country,
				us.setting_value AS orcid,
				COALESCE(uasl.setting_value, uas.setting_value) AS affiliation,
				r.date_assigned AS date_assigned,
				r.date_notified AS date_notified,
				r.date_confirmed AS date_confirmed,
				r.date_completed AS date_completed,
				r.date_acknowledged AS date_acknowledged,
				r.date_reminded AS date_reminded,
				r.date_due AS date_due,
				r.date_response_due AS date_response_due,
				(r.declined=1) AS declined,
				(r.unconsidered=1) AS unconsidered,
				r.recommendation AS recommendation
			FROM	review_assignments r
				LEFT JOIN submissions a ON r.submission_id = a.submission_id
				LEFT JOIN publications p ON a.current_publication_id = p.publication_id
				LEFT JOIN publication_settings asl ON (p.publication_id = asl.publication_id AND asl.locale = ? AND asl.setting_name = ?)
				LEFT JOIN publication_settings aspl ON (p.publication_id = aspl.publication_id AND aspl.locale = a.locale AND aspl.setting_name = ?)
				LEFT JOIN users u ON (u.user_id = r.reviewer_id)
				LEFT JOIN user_settings ugl ON (u.user_id = ugl.user_id AND ugl.setting_name = ? AND ugl.locale = ?)
			LEFT JOIN user_settings ugpl ON (u.user_id = ugpl.user_id AND ugpl.setting_name = ? AND ugpl.locale = ?)
			LEFT JOIN user_settings ufl ON (u.user_id = ufl.user_id AND ufl.setting_name = ? AND ufl.locale = ?)
			LEFT JOIN user_settings ufpl ON (u.user_id = ufpl.user_id AND ufpl.setting_name = ? AND ufpl.locale = ?)
				LEFT JOIN user_settings uas ON (u.user_id = uas.user_id AND uas.setting_name = ? AND uas.locale = a.locale)
				LEFT JOIN user_settings uasl ON (u.user_id = uasl.user_id AND uasl.setting_name = ? AND uasl.locale = ?)
				LEFT JOIN user_settings us ON (u.user_id = us.user_id AND us.setting_name = ?)
			WHERE	 a.context_id = ?
			ORDER BY submission

where the params are:

["en_US","title","title","givenName","en_US","givenName","en_US","familyName","en_US","familyName","en_US","affiliation","affiliation","en_US","orcid",1]

In this case en_US is the locale and 1 is the journal ID.

In addition to this query, you could also try looking at the reviewer/review associations for submission ID 5238 in the database.

Best,

Erik
PKP Team

Hello @ewhanson ,

Thank you for your response.
We have noticed other articles are missing as well, without any specific details that stand out.

This is the first time we noticed this and we are not sure if it happened before and we missed it, or it’s something that happened after upgrading to 3.3.0.8. Unfortunately, I cannot say.

Our journal is multilingual and has been using OJS since 1.5. However, we needed a manual install in september 2014. It has been upgraded since 2.x.

We’ll check the queries you have provided and report back as soon as we have some results.

@ewhanson ,

Here’s our first report on the situation:

select distinct ra.reviewer_id, ra.review_id, ra.submission_id, ra.recommendation from review_assignments ra, user_settings us where us.setting_name=“givenName” and ra.submission_id =5238;
±------------±----------±--------------±---------------+
| reviewer_id | review_id | submission_id | recommendation |
±------------±----------±--------------±---------------+
| 1034 | 3380 | 5238 | NULL |
| 988 | 3382 | 5238 | 1 |
| 732 | 3849 | 5238 | 5 |
| 13913 | 3855 | 5238 | 2 |
| 6382 | 3877 | 5238 | 4 |
±------------±----------±--------------±---------------+

SELECT r.stage_id AS stage_id,
 r.review_id as review_id,
 r.round AS round,
 COALESCE(asl.setting_value, aspl.setting_value) AS submission,
 a.submission_id AS submission_id,
 u.user_id AS reviewer_id,
 u.username AS reviewer,
 COALESCE(ugl.setting_value, ugpl.setting_value) AS user_given,
 CASE WHEN ugl.setting_value <> '' THEN ufl.setting_value ELSE ufpl.setting_value END AS user_family,
 u.email AS email,
 u.country AS country,
 us.setting_value AS orcid,
 COALESCE(uasl.setting_value, uas.setting_value) AS affiliation,
 r.date_assigned AS date_assigned,
 r.date_notified AS date_notified,
 r.date_confirmed AS date_confirmed,
 r.date_completed AS date_completed,
 r.date_acknowledged AS date_acknowledged,
 r.date_reminded AS date_reminded,
 r.date_due AS date_due,
 r.date_response_due AS date_response_due,
 (r.declined=1) AS declined,
 (r.unconsidered=1) AS unconsidered,
 r.recommendation AS recommendation
 FROM review_assignments r
 LEFT JOIN submissions a ON r.submission_id = a.submission_id
 LEFT JOIN publications p ON a.current_publication_id = p.publication_id
 LEFT JOIN publication_settings asl ON (p.publication_id = asl.publication_id AND asl.locale = pt_BR AND asl.setting_name = title)
 LEFT JOIN publication_settings aspl ON (p.publication_id = aspl.publication_id AND aspl.locale = a.locale AND aspl.setting_name = title)
 LEFT JOIN users u ON (u.user_id = r.reviewer_id)
 LEFT JOIN user_settings ugl ON (u.user_id = ugl.user_id AND ugl.setting_name = givenName AND ugl.locale = pt_BR)
 LEFT JOIN user_settings ugpl ON (u.user_id = ugpl.user_id AND ugpl.setting_name = givenName AND ugpl.locale = pt_BR)
 LEFT JOIN user_settings ufl ON (u.user_id = ufl.user_id AND ufl.setting_name = familyName AND ufl.locale = pt_BR)
 LEFT JOIN user_settings ufpl ON (u.user_id = ufpl.user_id AND ufpl.setting_name = familyName AND ufpl.locale = pt_BR)
 LEFT JOIN user_settings uas ON (u.user_id = uas.user_id AND uas.setting_name = affiliation AND uas.locale = a.locale)
 LEFT JOIN user_settings uasl ON (u.user_id = uasl.user_id AND uasl.setting_name = affiliation AND uasl.locale = pt_BR)
 LEFT JOIN user_settings us ON (u.user_id = us.user_id AND us.setting_name = orcid)
 WHERE a.context_id = 1
 ORDER BY submission;

ERROR 1054 (42S22): Unknown column ‘pt_BR’ in ‘on clause’

We added ticks and double ticks, but the error 1054 persists.

Hi @ramon,

I did a little bit of testing and it looks like all of the parameters I listed in the original post aside from the 1 will need to be in single quotes, e.g. 'pt_BR' or 'familyName'. That should take care of the error 1054.

Regards,

Erik
PKP Team

Hello @ewhanson ,

Thanks for the tip!
Working directly on the database now we have an output of 59,330 rows.
I guess now I can work with this output, importing into a spreadsheet and compare the results with the orginal report.

[UPDATE]
However, I have multiple instances of the same review round, review ID and reviewer in multiple rows… Not all… I can share the export file or the Google Spreadsheet…

[UPDATE 2]
SQL

SELECT r.stage_id AS stage_id,
 r.review_id as review_id,
 r.round AS round,
 COALESCE(asl.setting_value, aspl.setting_value) AS submission,
 a.submission_id AS submission_id,
 u.user_id AS reviewer_id,
 u.username AS reviewer,
 COALESCE(ugl.setting_value, ugpl.setting_value) AS user_given,
 CASE WHEN ugl.setting_value <> '' THEN ufl.setting_value ELSE ufpl.setting_value END AS user_family,
 u.email AS email,
 u.country AS country,
 us.setting_value AS orcid,
 COALESCE(uasl.setting_value, uas.setting_value) AS affiliation,
 r.date_assigned AS date_assigned,
 r.date_notified AS date_notified,
 r.date_confirmed AS date_confirmed,
 r.date_completed AS date_completed,
 r.date_acknowledged AS date_acknowledged,
 r.date_reminded AS date_reminded,
 r.date_due AS date_due,
 r.date_response_due AS date_response_due,
 (r.declined=1) AS declined,
 (r.unconsidered=1) AS unconsidered,
 r.recommendation AS recommendation
 FROM review_assignments r
 LEFT JOIN submissions a ON r.submission_id = a.submission_id
 LEFT JOIN publications p ON a.current_publication_id = p.publication_id
 LEFT JOIN publication_settings asl ON (p.publication_id = asl.publication_id AND asl.locale = 'pt_BR' AND asl.setting_name = 'title')
 LEFT JOIN publication_settings aspl ON (p.publication_id = aspl.publication_id AND aspl.locale = a.locale AND aspl.setting_name = 'title')
 LEFT JOIN users u ON (u.user_id = r.reviewer_id)
 LEFT JOIN user_settings ugl ON (u.user_id = ugl.user_id AND ugl.setting_name = 'givenName' AND ugl.locale = 'pt_BR')
 LEFT JOIN user_settings ugpl ON (u.user_id = ugpl.user_id AND ugpl.setting_name = 'givenName' AND ugpl.locale = 'pt_BR')
 LEFT JOIN user_settings ufl ON (u.user_id = ufl.user_id AND ufl.setting_name = 'familyName' AND ufl.locale = 'pt_BR')
 LEFT JOIN user_settings ufpl ON (u.user_id = ufpl.user_id AND ufpl.setting_name = 'familyName' AND ufpl.locale = 'pt_BR')
 LEFT JOIN user_settings uas ON (u.user_id = uas.user_id AND uas.setting_name = 'affiliation' AND uas.locale = a.locale)
 LEFT JOIN user_settings uasl ON (u.user_id = uasl.user_id AND uasl.setting_name = 'affiliation' AND uasl.locale = 'pt_BR')
 LEFT JOIN user_settings us ON (u.user_id = us.user_id AND us.setting_name = 'orcid')
 WHERE a.context_id = 1;

The columns on the output are these:

  • stage_id
  • review_id
  • round
  • submission
  • submission_id
  • reviewer_id
  • reviewer
  • user_given
  • user_family
  • email
  • country
  • orcid
  • affiliation
  • date_assigned
  • date_notified
  • date_confirmed
  • date_completed
  • date_acknowledged
  • date_reminded
  • date_due
  • date_response_due
  • declined
  • unconsidered
  • recommendation

Hi @ramon,

I’m not sure what might be causing the multiple instances. You could share a sample exported file with an example of this happening via direct message. It would also be helpful to know what the review round assignments, etc. look like for that submission as well.

One possible explanation is that none of these queries use the GROUP BY statement, so rows with the same review round, review ID, and reviewer could appear for some of the JOINs (a row that matches givenName, a row that matches familyName. I suspect this might be the cause of it. The rows are further processed when creating the reviewer report, which happens here:

Hope this helps!

Regards,

Erik
PKP Team

Hi @ramon,

Thanks for sharing your spreadsheet. Unfortunately I don’t think I have any further suggestions. I believe the duplicate entries are appearing for the reason I mentioned in my previous comment, so I wasn’t really able to see anything helpful there.

As for the larger issue, I think I’ve hit the limit on my knowledge here, but it’s possible others in the community may know more.

Regards,
Erik

Hello everyone,

Still no success at fixing the review report on our version of OJS.
I have a folder to be shared with support, for access to the CSV.

There are tons of repeated entries as you can see from the images (submission ID hidden for privacy).

Is that normal?

Is there an SQL query I can run to select reviewers that acted during a period of time (from date A to date B)?

image

image

image

Anyone??

This is a bit urgent as we need to publish a late issue and we provide a list of reviewers of the period, to give some credit for the hard work.