Log reviewers response

[MrRob100]

A function so that editors can log the response decision from reviewers - e.g if the reviewer emails the editor rather than logs it themselves in OJS. A 'Log Response' response will show on a review item in the editorial workflow if a review confirmation hasn't already been made.

PRs https://github.com/pkp/ui-library/pull/350 https://github.com/pkp/pkp-lib/pull/10379

[MrRob100]

@Devika008 Can you take a quick look on this design please

[Devika008]

Hello Rob,

Could you allow me time till Monday to get back on this.

[Devika008]

Hello Rob,

Everything looks good but just made modifications on the first screen based on some design principles I follow through all designs. Please review and let me know if you are okay with it.

[asmecher]

Just a heads-up: While I'm not opposed to adding this feature (reviewer communications are always going to be delicate and need extra accommodation to avoid losing reviewers), this does go counter to our general strategy of reducing the number of actions an administrative user (e.g. a journal editor or manager) can take on a third party's behalf (e.g. a reviewer).

Our general approach is to make more use of invitations that propose changes to a 3rd party but allow them to accept/reject them.

In this case, that's what we already have -- reviewers receive an email inviting them to participate, and they can either accept or reject. Reviewers will still tend sometimes to reply to emails rather than reading the instructions, so there's a need to accommodate that.

My only alternative idea so far has been to allow OJS to receive emails from reviewers directly, and parse out their intentions. However, parsing "thanks, but not this time" accurately into a "decline" is not going to be easy, so I think we're left with the spec here as a next-best!

[jardakotesovec]

In general when we are creating new UIs in Vue.js we also extend existing API to cover the new use cases.

To be able to handle this 'Log Response' action - @ewhanson could you please look into it and advise where this could be added in our API?

[ewhanson]

Hey @MrRob100, I've done a bit of thinking and think the best approach for an API endpoint for this use case would be as such:

PUT /reviews/{submissionId}/{reviewRoundId}/confirmReview with a body value of decision: "accept/decline" to handle the actual confirmation decision. This can go in the PKPReviewController.php. There's currently only one reviewer API endpoint so I'd recommend looking at PKPSubmissionController.php for some examples of how the API endpoints are constructed, perhaps specifically the saveContributorsOrder route. This has a good example of a PUT request that includes some body params. The Route::midleware group directly above dictates which roles are authorized to use this endpoint.

The logic you already have will be simple enough to move into the API endpoint, it will just require some additional checks to make sure everything with the request is correct (e.g. the reviewer round matches the submission, etc.). That should help get you started, but feel free to let me know if you run into anything or have any other questions once you get going.

[ewhanson]

Hey @MrRob100, I've had a look at the pkp-lib side of things, and it looks good! 👍 Just a few comments in the PR itself. I was also curious where all the translations for the new locale keys came since the usual process is for them to go through Weblate once the English ones have been merged. Were they put through Weblate already?

[jardakotesovec]

@MrRob100 Just did fresh review of the ui-library. Just couple small tweaks.

@Vitaliy-1 Could you scan through the pkp-lib part as its workflow related? Thanks!

[jardakotesovec]

ui-library part is now approved

Lets wait for @Vitaliy-1 green light on pkp-lib :-).

Thank you!