Expose recommendOnly editor recommendations for Workflow page

[jardakotesovec]

Describe the context

While migrating the workflow page to the side panel, some of the data originally exposed in workflow handler now needs to be exposed via API.

To support recommendOnly functionality, we need following information:

currentUserCanRecommendOnly: Boolean

This indications whether current user is assigned to given submission with the recommendOnly flag. We already have this information exposed on submission.stages in Review stage as currentUserCanRecommendOnly. So thats covered.

editorOnlyRecommendations: [{id, label}]

To present list of recommendations to deciding editor, list of the recommendations is needed.
Preferably as array of objects, including the label property, so there is possibility in future to include more details if needed. Exposed on same place as currentUserCanRecommendOnly

This probably should not be present when current user is recommending editor, as we don't present the recommendations from others to her/him.

Reference implementation for allRecommendations - https://github.com/pkp/pkp-lib/blob/main/pages/workflow/PKPWorkflowHandler.php#L731

currentUserLastRecommendation {id, label}:

This on the other hand would be exposed for recommend only editor, to be able to display his last decision:

Exposed on same place as currentUserCanRecommendOnly , same data shape as object in editorOnlyRecommendations

Reference implementation for lastRecommendation - https://github.com/pkp/pkp-lib/blob/main/pages/workflow/PKPWorkflowHandler.php#L731

isDecidingEditorAssigned: Boolean

This I could theoretically derive from Participants, but preferably this would be backend calculation if possible, but opened to options.

Reference implementation on workflow page: https://github.com/pkp/pkp-lib/blob/main/pages/workflow/PKPWorkflowHandler.php#L627

What application are you using?
OJS, OMP or OPS version 3.5

[jardakotesovec]

@Vitaliy-1 Is that feasible? Of course opened to other ways to expose it.

Technically this would be needed only on the /submissions/{submissionId} endpoint, so we could potentially skip on the listing if that would affect performance. But I already suspect that you the decisions are being fetched on the listings anyway?

Edit: Information that user already provided recommendation would be actually needed on submission listing, as we want indicate that he is done. So if the fields asked above would not require some per submission sql queries, but only reusing fetched decisions and participants - than it might be simplest to having that both on submission endpoints and the _submission listing.

[jardakotesovec]

@Vitaliy-1 As I had more time to think about it, I would be leaning towards following:

1. To get list of recommendations, I would create new issue to improve the submission/{submissionId}/decisions endpoint, to include some filterying query params and also fine tune the permissions, so also sub-editor can use that endpoint, but only for stages he is assigned to. Once having that I should be able to get the recommendations to list them.

2. Than other recommend only related things should be possible to derive from stage-assignments, without getting decisions involved.

For permission purposes, I need stageAssignments per stage - thats why I was thinking of extending currentUserAssignedRoles in #10411, to not only get list of the assigned role ids, but include also information about recommendOnly and canChangeMetadata.

Here are information that I would need to get:

• is current user recommend only
• is current user deciding editor (meaning there are other recommend only editors, but not current one)
• is deciding editor assigned
• can current user change metadata
• what roles is current user assigned to for each stage

Please once you will be able to look into this - reach out. So we can discuss some details about these properties (where and how to include them). As optimal implementation might be to query for all stageAssignments, including the roleId and stageId (from the related tables). And then in PHP filter it by stageId and calculate the properties above per stage. But need your help with to think it through and implement properly.

[jardakotesovec]

As alternative, opened to also just include (to submission object) reduced version of stage assignment for every stage and derive the above from it.
We could just include (in each stage):

• userId
• roleId
• recommendOnly
• canChangeMetadata

Tagging also @asmecher and @ewhanson for opinion around that.

Edit: What feels good about this option is that exposed data would be less ui specific, and it still would be quite simple to compute the ui specific needs on client side.

[jardakotesovec]

This is summary of above:

So what I think could work quite well:

1. Using stage assignments (per stage) on submission listing (inside every stage).
   a) Either expose the stage assignments basic information (userId, roleId [the permission role id], recommendOnly, canChangeMetadata) and calculate the recommend only things from it client side
   b) Or calculate these directly on server side from stage assignment

Here are the information I need to derive from stage assignments either on server or client:

• is current user recommend only
• is current user deciding editor (meaning there are other recommend only editors, but not current one)
• is deciding editor assigned
• can current user change metadata
• what roles is current user assigned to for each stage

Both approach would work for our UI - and the question between a) and b) is more about designing the api - to be bit either bit more specific to our use cases - or exposing more general data which can be used for wider range of cases by different consumers.

2. The actual recommending decisions - best to my current knowledge of things - I don't really need it on submission listing. I need to show specific recommendations on workflow page. So that would be fetching it just for one submission at the time. Therefore improving the decision endpoint seems like good fit for that.

[ewhanson]

As alternative, opened to also just include (to submission object) reduced version of stage assignment for every stage and derive the above from it.

@jardakotesovec, I do think this would be a good approach. As you say, this is a less UI specific approach and allows for the client to concern itself with the derived state it needs based on this information.

[jardakotesovec]

To improve existing decision endpoint I created separate issue: #10465

[jardakotesovec]

Closing this one in favour of #10360

[taslangraham]

Closing this one in favour of #10360

Hi @jardakotesovec, the link you provided is this same issue

[jardakotesovec]

Sorry this is correct one - #10480