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
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.
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.
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