Pkp-lib: Improve editor control over reviews

Created on 9 May 2017  路  29Comments  路  Source: pkp/pkp-lib

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.

Community Priority

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:

  • decline on the behalf of the reviewer (I know there is a "unassign reviewer", but if the user declines via email, it would be important to mark it as "declined", not just remove the assignment)
  • accept on the behalf of the reviewer
  • and fill the form through the editorial workflow on the behalf of the reviewer
    would be needed

All 29 comments

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 fill the review form for the reviewer (especially situations where the reviewer does not like to use systems like OJS but the editor wants to have the review saved the same way as other)
  • ability to remove a review request if reviewer is not answering
  • ability to change the status of an accepted review request, if the reviewer changes her mind. And vice versa.

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:

image

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:

  • decline on the behalf of the reviewer (I know there is a "unassign reviewer", but if the user declines via email, it would be important to mark it as "declined", not just remove the assignment)
  • accept on the behalf of the reviewer
  • and fill the form through the editorial workflow on the behalf of the reviewer
    would be needed

I fully agree with @ajnyga

Are there any workaround this issue. I am concerned about the following case brought up by @ajnyga :

  • ability to change the status of an accepted review request, if the reviewer changes her mind. And vice versa.

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:

  • ability to change the status of an accepted review request, if the reviewer changes her mind. And vice versa.

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:
Capture

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:

  • When trying to add a reviewer, I get DB Error: Column count doesn't match value count at row 1.
  • When a review is cancelled, it still appears as an Active Review in the reviewer selection list. Probably the calculation for all of the reviewer stats need a review: https://github.com/pkp/pkp-lib/blob/stable-3_1_2/classes/services/queryBuilders/UserListQueryBuilder.inc.php#L428-L489.
  • There's no way to undo this action. An unassigned reviewer can be re-added, but a canceled review can not be. Given the use-case, a reviewer probably doesn't want to re-add them. But editors are bound to make mistakes or change their minds. Maybe a "Resume assignment" button should appear on a cancelled review?

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

  1. When a reviewer has accepted a review but failed to deliver, the editor now has the ability to cancel the review:

image

  1. Clicking that permits composition of an email:

image

  1. The review will now show the editor's reviewer list as "cancelled":

image

  1. When selecting a reviewer, you'll see an indication of how many cancelled reviews they have (this will be a pretty good indicator of unreliability):

image

  1. For the reviewer, cancelled reviews still show up in their queues, but indicated as such:

image

  1. They'll still be able to look at the submission, as they already accepted it (and e.g. may have seen the author's information). However, the review is now read-only, i.e. they cannot change anything:

image

  1. Editors can reinstate cancelled reviews by clicking a link similar to the one that was used to cancel it. Similarly, this leads to an email compose box. There is a new email template for this purpose.

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)

Was this page helpful?
0 / 5 - 0 ratings