In OJS, a reviewer cannot access his/her recommendations from a previous round.

[pilasou]

As a reviewer reinvited to a new review round, I would like to be able the see the evaluation I provided in previous rounds.

In OJS, reviewers that are being invited to different review rounds on the same submission cannot access what was their previous recmmandations.

This improvement will offer the opportunity to reviewers to access their previous review reports and thus, better determine how the author made his/her changes to the manuscript.

The reviewer will be able to access his/her Previous round reports by clicking on a Round button on top of the reviewer process page (as shown below).

When clicking on a cycle button a new window open containing the following information:

• Recommandation
• Forms informations
• Review file sent
• Cycle dates
• Article version reviewed during preceding round

PRs:

Update (2024-04-02)
pkp/ui-library#313 (jardakotesovec repository)
pkp/pkp-lib#9526
pkp/ojs#4148

Initial:
#9526

OMP adaptation PRs:
OJS: pkp/ojs#4258
OMP: pkp/omp#1556
OPS: pkp/ops#668 TESTS ONLY

PKP-LIB: #9920 Initial Commits for PKP-LIB included

How to test?

1. Make a submission and send it to the Review step.
2. Invite one reviewer.
3. Connect as reviewer and complete the review (fill the form and add a file).
4. As editor, Request revision and select Revisions will be subject to a new round of peer reviews.
5. As an author, submit revision.
6. As editor, open a 2nd round of review.
7. Invite the 1st round reviewer.
8. Connect as the reviewer.
9. On top of the review page, you should see the Round 1 bouton.
10. In the new window, the reviewer can access its answers (forms and files).

[asmecher]

PR: #9526

@Vitaliy-1, could you review this? Thanks!

[Vitaliy-1]

Thanks, @nibou230! I left a couple of comments.

[pilasou]

Hi, @Vitaliy-1, just to let you know, I am a colleage of @nibou230, he will be on vacation for the next few weeks. Back in January. We will follow up when he comes back. Thanks!

[jardakotesovec]

@nibou230 Hi, thanks for the contribution, its certainly useful feature. Only drawback is that this is built on legacy stack and we aim to avoid adding new functionality on this old stack, because that means that we would need to migrate it to newer stack at some point anyway.

I would like to ask whether you would have some dev capacity & interest to build this feature on newer stack?

It would be creating frontend part in Vue.js (significant portion of OJS is already on Vue.js) and creating relevant API endpoints that the frontend would use.

If so, we would provide support and guidance how to do it.
In particular
frontend part: @jardakotesovec
api: @defstat
UI/UX: @Devika008

Let us know what you think

Thank you!

Jarda

[nibou230]

Hi @jardakotesovec, if our planning let me some spare time, I will do my best to convert this feature on the newer Vue.js stack. Do you have any portion of the application (on Vue.js) that would be similar so I could take some inspiration from it?

Hello @Vitaliy-1, thanks for the comments, if they are still relevant, I will take a look at those once the refactor is done.

[jardakotesovec]

@nibou230 That would be great! Some of the things that we are currently using are quite new, therefore there is not enough examples, so I decided to create boilerplate to show how things should come together. New composition API from vue3 might look bit intimidating at first, but once you get use to it, its very expressive way to write logic for components.

Once the tests run, I will merge it to main (probably tomorrow morning), so you can rebase against main and start moving things over.

PR: ui-library, pkp-lib, ojs

Since I will be merging unfinished work to the main branch, its behind feature flag, to enable displaying of 'History buttons' adjust your config.inc.php to include:

[features]
enable_review_round_history = On

Now there are two big parts to tackle:

API

We already have many API endpoints to serve data - https://docs.pkp.sfu.ca/dev/api/ojs/3.4 . Unfortunately the data you are after are not exposed yet. So it will be necessary to introduce new ones that would cover needed metadata.

Can someone more familiar with that provide bit of guidance and suggest some good modern examples to follow? Pinging @asmecher @Vitaliy-1 @defstat

In boilerplate for demonstration purposes I am using the /submissions/{submissionId} endpoint to get submission metadata.

Styling

Thats probably last thing to tackle.
For new UI we are using TailwindCSS - please checkout our documentation in storybook.

Pinging @Devika008 in case she would have capacity to mock what the UI could look like. If not - we will improvise :-).

Also note that one of the parts is listing of reviewer files - I will be building same Vue.js component hopefully in ~2weeks for new submissions listing. So thats something I would provide as well (but that handles just rendering, its still necessary to create API to fetch them).

Other notes

• Yes I noticed that buttons shows Round 1, and I am tempted to adjust the translations, but want to check with the team first, rather than fallback to v-html which is way too permissive, just to be able pass the html entity.
• Also feel free to explore the storybook that I linked above for additional technical details - I have not promoted it, as I am still working on documentation, but its lots of info already there. More officially it will be introduced in ~2/3weeks.

[nibou230]

Wow, thank you so much @jardakotesovec!

I was quite lost trying to figure out how I could start this and how to link the component/page to the reviewer handler section. I'm more of a C# type of developer so it's far from my usual code. :-)

This boilerplate will help me a lot. I'll wait until tomorrow for this code and meanwhile I will look at how I should expose the required data.

Should I create a whole new API controller or should I add a method or two inside the current submission one?

[jardakotesovec]

@nibou230 Hi Nicolas, its now merged on main. If you have any further frontend related questions or feedback, let me know. And hopefully on API side someone will chip in shortly.

[defstat]

Hi @nibou230! Regarding the API, all the data that you are after seem to be contained into the Review process, so it could make sense to start with working on a separate API Controller and add your endpoints there. One example that you could investigate is the JATS API controller. If you have any questions regarding that don't hesitate to ask.

Depending on the URLs that the newly developed endpoints will listen to, there could be some specific changes that you need to make in order for those to work correctly, but I suggest to see those if there is such a need.

Please take into account possible differences between the OJS and OMP applications, so that each application (OJS or OMP) specific changes will be developed out of the PKP-LIB API Controller, and leave common changes (that cover both OMP and OJS) into the PKP-LIB API Controller.

You could check (for example):

1. Submission API Controller for OJS
2. Submission API for OMP No specific changes needed for OMP
3. Submission API Controller for PKP-LIB - Common for all applications

[nibou230]

Hi @defstat, thank you for the help.

I'll look at the Jats controller and make another one specific for the reviews.

I understand the point to split what should be common or specific to an application, but I don't know OMP at all. I will do my best and if you guys spot something that should not be inside PKP-LIB, tell me and I will make the appropriate change.

[defstat]

@asmecher @jardakotesovec @Devika008 OJS, OMP, PKP-LIB merged into main.

@pilasou @nibou230 This feature is now part of OJS - Thanks so much for your contribution!

[pilasou]

@jardakotesovec @Devika008 @asmecher @defstat Thank you so much! And special thanks to @nibou230 ! :) That was quite an effort and seeing this feature added to OJS is rewarding to say the least. Encore une fois merci à toutes et tous!