How to revert a Review Submitted state?

The editor in one of our journals clicked Confirm in the Review Details and now this review is set as Completed. If I try to Revert Decision I can get to Review Submitted, which is definitely not the case, as nothing was submitted.

The reviewer in question was Overdue, is there a way to revert this “review submitted” state?
Also, I’ve found an Issue related to that possible mistake when clicking Confirm that hasn’t been updated in a while: Review Detail Confirmation button · Issue #6353 · pkp/pkp-lib · GitHub

Hi @luizborges,

Thanks for your post. Would you mind indicating which version of OJS you’re using?

Also, I wanted to note this issue as well: Allow a review round to be canceled after it has been created · Issue #3585 · pkp/pkp-lib · GitHub - there will be some forthcoming changes in OJS 3.4 in the ability to revert reviews. I’m not totally sure how it will relate to your particular use case though.

-Roger
PKP Team

Hello Roger,
I’m on 3.3.0.13.

I’ve found this other issue and although related I’m not sure it is the same issue I’m having.

What I described, is that if I just click on Confirm in the Review Details, it finishes this review and there is nothing I can do to revert back, and since the reviewer was already assigned to it, they cannot finish their review now.

The Review is now set as Complete, and Revert Decisition just mark it as “Submitted”, even though nothing was actually submitted.

@rcgillis any follow up on this issue?

Hi @luizborges,

Have a look at this issue:

At a glance, I think it’ll resolve the problem you’ve identified, although indirectly. This has already been implemented for the forthcoming 3.4.0 release – watch for an announcement very soon about community testing opportunities.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher, I’ve read through the issue but I’m not sure it is does what I need (revert a misclicked “Confirm” in the windows). Also, since there are many commits and my installation is not tied to github, I would have to manually patch each of the commits, something that is prone to create some hidden bug somewhere.

What I was able to do was change setting the Confirmation Date to NULL on review_assignments table, this allowed me to fill the review again, but created some bad trail (the log isn’t reverted and the review is still set as unconsidered=2, due to the redundancy in the way the review is recorded in the database). It worked, but was clunky and I just hope it doesn’t break anything in the future.

I won’t be able to test much of the 3.4 beyond basic funcionality, but I’m eager to see it in production.

Hi @luizborges,

I actually wouldn’t recommend trying to back-port the changes to 3.3.0; there has been a lot of infrastructural work done on the main branch and that would make it tricky.

The work I was thinking of is related to the “considered” states that a review can have; these have been expanded with 3.4.0 and the review’s movement between states has been clarified. I don’t recall the details well but I believe it may address your situation as well.

Meanwhile your work-around of resetting the state in the database should hold you for the moment, even though it’s not ideal!

Thanks,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 16 hours. New replies are no longer allowed.