Bug 5060 - Allow Editors to reset Reviewer access
Allow Editors to reset Reviewer access
Status: NEW
Product: OJS
Classification: Unclassified
Component: Reviewers
3.1
PC Mac OS X 10.3
: P5 enhancement
Assigned To: PKP Support
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-17 21:08 PST by James MacGregor
Modified: 2013-05-29 16:14 PDT (History)
1 user (show)

See Also:
Version Reported In: 2.3.1
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2010-01-17 21:08:01 PST
Inspired by http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=5657&start=0. 

We've had occasional requests for some sort of functionality that would make recovering from botched reviews easier than starting a new round of review (especially an issue if the submission has a large number of reviewers currently assigned to it). However, I understand that this functionality may not currently exist for a reason -- that is, to stop Editors from too easily mucking around with the review process, and to preserve the workflow/submission history. 

Possible workarounds, off the top of my head: 

-- The easiest option would probably be to allow Editors the ability to edit review form data after it's been signed off by the Reviewer. Is this allowing too much liberty? 

-- Include a "nuke review" button option, available to Editors, which would erase the review totally, and place the Reviewer in an unassigned position relative to the review, so that they can be reassigned. (Possibly even move the completed/botched review into Regrets/Cancels, marked as botched.)

-- Include a "reset review" button option, available to Editors, that would just reset the review to it's initial, not-yet-accepted state. The reviewer would still be assigned, but they'd have to go through the review process entirely.
Comment 1 Alec Smecher 2010-04-30 10:46:35 PDT
I think all that would be required is a removal of the final recommendation (and an entry in the submission's event log); this wouldn't erase prior comments / uploads / etc., but would allow the review to amend.
Comment 2 James MacGregor 2010-04-30 10:59:46 PDT
(In reply to comment #1)
> I think all that would be required is a removal of the final recommendation
> (and an entry in the submission's event log); this wouldn't erase prior
> comments / uploads / etc., but would allow the review to amend.

Sounds good to me, Alec.
Comment 3 Alec Smecher 2010-07-20 12:43:44 PDT
Deferring.