The Editor should be able to override a reviewer's "Accept" in case they later change their mind. See http://forum.pkp.sfu.ca/t/canceling-an-already-accepted-review-request-ojs-3-0-2/30728.
And http://forum.pkp.sfu.ca/t/login-as-for-reviewer/30844/3 -- apparently the editor can't fill in a review form for the reviewer. (Suggestion there is to add Log In As; not sure that's the best way.)
Is this still an issue? I seem to be able to read a review and change the decision.
@NateWr we are lacking at least:
ability to remove a review request if reviewer is not answering
Are you looking for something different from the "Unassign Reviewer" option?
ability to change the status of an accepted review request, if the reviewer changes her mind. And vice versa.
I think you mean if a reviewer has refused or accepted the request, you want the editor to be able to change that decision, correct? Maybe if the editor could just remove that assignment and make it again that could work, if it preserves the original decline in the editorial history.
I think you mean if a reviewer has refused or accepted the request, you want the editor to be able to change that decision, correct? Maybe if the editor could just remove that assignment and make it again that could work, if it preserves the original decline in the editorial history.
Correct. But at the moment, if a review request gets declined, the editor can not remove the declined request. The "Unassign reviewer" is only visible before the reviewer has responded.
Are you looking for something different from the "Unassign Reviewer" option?
As above. One scenario could be that the reviewer first accepts the request, but then realizes that she can not deliver one and asks the editor to cancel. However, the editor really has no way of doing it and if the journal has automatic reminders there are potentially angry emails going around :)
There is also this recent request to remove overdue requests. But I am not sure why it would be necessary if the reminders are already sent. https://forum.pkp.sfu.ca/t/how-to-remove-reviewers-with-overdue-status/34305/4
I think this is not mentioned above: reactivating a reviewer that initially declined: https://forum.pkp.sfu.ca/t/reactivating-a-reviewer-who-initially-declined-a-review-in-ojs-3-1/36402
I second having a "Login As" link under the Reviewer's name, for convenience's sake:

Even though there are ways to unassign, fill out the form and send attachments, often times you need to "see what the reviewer is seeing" for troubleshooting purposes.
It's much faster than going all the way to users -> search for the user -> Login As
Note that "Login as" was added in 3.1.1.2.
However, it is not a good solution in multi journal installations, because the journal editor can not log in as an user who is registered in several journal.
So the ability to:
I fully agree with @ajnyga
Are there any workaround this issue. I am concerned about the following case brought up by @ajnyga :
I believe a solution would be to allow the editor to Reinitialize/Reset the review request, as long as he/she has not sent Recommandations.
Agreed. This would be a very useful feature:
We have had several cases of reviewers accepting to do a review, but then never delivering one even after reminders. We have also had cases where a reviewer has accepted to do a review, but upon receiving the reminder has informed us that he can no longer do the review.
It is very, very unfortunate that there is no way of removing the reviewer after he/she has responded. In OJS 2, it was easy to accept/decline on behalf of the reviewer and you also had the CANCEL REQUEST link. Does anyone know if this feature will come back soon?
@openacademia It is not pegged to a milestone which means it isn't in our plans for the immediate future.
We now have four community members expressing an interest so I've put the Community Priority label on it. That can help it stand out from other issues, but it's still no guarantee of forward movement.
That said, I don't see any objections here, so it's just a matter of priorities and dev resources.
Scenario: an OJS reviewer accepts a review, but never delivers. The editor runs out of time and decides to close the review assignment.
History: OJS 2.x had a "Cancel Review" feature, leading to an email compose window and REVIEW_CANCEL email template. This fed the cancelled column in review_assignments (a boolean flag). Downstream users of the data knew to watch for cancelled=1 to indicate that the review was closed by the editor. (Not sure how date columns worked with this, e.g. date_completed.)
Proposal: Reconstitute the cancelled column in OJS3. There is already the REVIEW_CANCEL email template ready for use. This will permit old data to be used in upgrades to OJS3 versions including this change. OJS installs that were upgraded to OJS3 before this proposal is implemented will be missing the cancelled column in review_assignments and may need to run an UPDATE to re-fetch that column's data. (To be written, but not hard.)
Reviewer Grid after review cancelled:
DRAFT Pull request: https://github.com/pkp/pkp-lib/pull/4724 [outdated -- closing! -AS]
@NateWr, I'm getting Javascript errors that are doing my head in -- probably quick for you to spot. Mind taking a quick glance over the above PR? It's breaking the reviewer selection stuff.
What are the JavaScript errors that you encountered? I haven't been able to trigger any JS errors, but I have run into other issues:
DB Error: Column count doesn't match value count at row 1.Well shoot -- thanks, @NateWr, I think that DB error explains it. I'm not sure why I was convinced it was a JS/Vue issue. Will continue working on the other aspects.
@NateWr, the above 3 PRs add the stats and "reinstate" features that were missing from the previous implementation. I also moved everything to master as we can't make schema changes on stable-3_1_2.
I ended up losing much of this code in a git debacle and restoring it by grabbing an old diff from my terminal history (!!!) so I apologize for anything boneheadedly missing. I think I got it all.
Would you mind having a review?
Thanks, @NateWr, this was a helpful exercise in getting acquainted with the Vue/ListPanel stuff. The tests are currently failing but I'm pretty sure that's because the master branch of ui-library is being checked out rather than my fork.
PRs (as before):
Here's how it should work now...






For bonus points, users who upgrade from OJS 2.x to OJS 3.x as long as this code is in place when they perform the upgrade will have the cancelled status for OJS 2.x data preserved. (Uses who upgraded to OJS 3.2 or newer via an interim 3.x version will have to run a cross-database query to restore this data.)
This looks great, @asmecher. Regarding #5 and the my queue submission list: will this eventually be removed when the article is accepted, declined or published? I'm just thinking about cancelled reviews accumulating over time and cluttering up the queue, especially for large journals.
Regarding #5 and the my queue submission list: will this eventually be removed when the article is accepted, declined or published?
Yes, IIRC the reviewer lists move submissions over to the archive based on the submission's status, not the review's status. So it'll jump over once the submission is published or rejected.
Thanks, @NateWr, all merged & ported to OMP master as well.
@amandastevens, tagging you -- see https://github.com/pkp/pkp-lib/issues/2508#issuecomment-493619146, which documents the UI changes caused by this!
(I think that completes all the issues raised in this entry -- and there are several -- at least in a basic way. Please re-open or flag if not!)
Can you cancel a declined review? We have had situations where reviewer first declines, but then contacts the editor that she can do the review anyway. However, the current release prevents the editor from assigning the same person again because she has already declined.
@ajnyga, I've moved that request over to this new issue: https://github.com/pkp/pkp-lib/issues/4789
(This issue is getting pretty cluttered)
Most helpful comment
Note that "Login as" was added in 3.1.1.2.
However, it is not a good solution in multi journal installations, because the journal editor can not log in as an user who is registered in several journal.
So the ability to:
would be needed