Enhance submission schema with review assignment data

[Vitaliy-1]

• Reviewer name
• Review method
• Anonymize review assignment data for blind reviews

[Vitaliy-1]

PRs
pkp-lib: #9984
OJS: pkp/ojs#4289
OMP: pkp/omp#1587
OPS: pkp/ops#702

[Vitaliy-1]

@bozana, can you take a look at these PRs? This solves the problem of showing additional review data on the new submissions list. I've added it to the submission schema, so it's available also from submission API endpoint for authors and reviewers, which means that sensitive data should be anonymized if review isn't open.

[bozana]

Hi @Vitaliy-1, the PRs look good to me! Please, go ahead...

[Vitaliy-1]

@jardakotesovec, I've updated the PR according to our discussion regarding the _submissions/assigned endpoint for authors, can you take a look?

[jardakotesovec]

@Vitaliy-1 Here is idea.. likely naive as I am still trying to grasp how the permissions/access are handled, but here we go..

We already have challenge on multiple API endpoints - where if user has multiple roles (reviewer/author/editor), we might return more data than we want - like incorrect dashboard views, or incorrect result to particular dashboard view.

So how about if we introduce more general concept where I can set in the API (probably via query param) that I want to reduce the roles - some top layer would reduce the roles I am accessing the system with and than the API would have easier time to reason about things, if they for example think I am just author - it won't lead any additional data, just because I happen to also be editor.

With that - would not be possible to have just simple implementation for review assignment on the submissions schema, where it would anonymise them based on 'having just author role and review assignment is not open'?

[jardakotesovec]

Hmm.. this probably would not work.. Because I guess that some editor roles can't access all submissions unless they are assigned to them, right?

So when API would be used directly - than theoretically editor who is also author could access more than he should with the approach suggested above.