Submission history shows review actions to author, despite review type

We’re using OJS3.0.1 for a couple of journals here at QUT.

Recently we were asked to investigate the functionality of the review types offered by the platform, to ensure that the journal owners could reply upon the presented options (Open, Blind, Double Blind).

For all selected review types we’ve found that the author who uploaded the submission can always view the submission history, which shows the full detail of which reviewer is assigned to which submission, along with their final decision.

Looking at the code, the submission history retrieval looks fairly linear. I can’t see where it filters on the context of the current user + the submission review settings.

Is there a way to filter the submission history view to preserve the integrity of the review process?

From where in the author view are you accessing the submission history?

I mean do you have a page something like authorDashboard/submission/608 open or where? I can not figure out a way to access the submission history as an author.

It could be that it is a bug in 3.0.1. It would be a good idea to upgrade to 3.0.2. There are a lot of similar bugs in 3.0.1.

The submission history is viewable from the dashboard when an author logs in. They can see their authored submissions, and when expanding the small arrow to the left of the submission, can select “More Information”.

This calls a few handlers. The event log data is retrieved using the submission event log grid handler, which during its loadData function calls the submission event log DAO to get all events by submission id.

There is no filtering on the output, it’s simply merged with the email log DAO output and presented to the user. This is consistent across the OJS releases.

We’re planning to enhance this component to give the journal managers more confidence on the review process, as they’re quite alarmed at the ability for authors to see this information.

I just wanted to check to see if anybody else had noticed this before coding around it.

Hi @joe,

I believe this issue was fixed in issue 2047, with the fix released in OJS 3.0.2. I’d suggest upgrading to that release, as it includes a lot of fixes and tweaks.

Regards,
Alec Smecher
Public Knowledge Project Team

hah, I thought that this sounded familiar :smiley:

1 Like

G’day @asmecher,

I just setup a 3.0.2 environment and had a look around.

You’re absolutely correct, the 3.0.2 release addresses this issue.

We’ll now move to upgrade to that version as soon as possible.

Thanks again,

Joe

1 Like