Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional fields in Submission schema in API for 3.5 #10480

Open
jardakotesovec opened this issue Sep 27, 2024 · 0 comments
Open

Additional fields in Submission schema in API for 3.5 #10480

jardakotesovec opened this issue Sep 27, 2024 · 0 comments
Assignees
Labels
Enhancement:2:Moderate A new feature or improvement that can be implemented in less than 4 weeks.
Milestone

Comments

@jardakotesovec
Copy link
Contributor

On the meeting we agreed to include following fields to the submission schema. These are computed fields from stage assignments.

We agreed that keeping business logic on server side is better to not spread business logic too much between server side and client side. All these fields also are very business specific information, not really UI specific. Client side makes its own decision how to present things based on these flags.

Opened to different names, but these should be quite self-explanatory.

Submission listing /_submissions

  • isCurrentUserRecommendOnly
  • isCurrentUserDecidingEditor
  • isDecidingEditorAssigned
  • canCurrentUserChangeMetadata
  • currentUserAssignedRoles

Workflow side modal /submissions/{submissionId}

  • isCurrentUserRecommendOnly
  • isCurrentUserDecidingEditor
  • isDecidingEditorAssigned
  • canCurrentUserChangeMetadata
  • currentUserAssignedRoles
  • currentUserRecommendation
  • recommendations

Description for each field

isCurrentUserRecommendOnly (per stage)

  • boolean
  • meaning is that current user is assigned with the recommendOnly flag
  • recommend only flag is relevant on multiple stages to decide what user can do, not only on review stage
  • would be calculated for every stage

isCurrentUserDecidingEditor

isDecidingEditorAssigned

  • boolean
  • If there is at least one recommendOnly editor - this indicates whether there is also ROLE_ID_MANAGER or ROLE_ID_SUB_EDITOR in stage assignments without recommendOnly flag
  • this can be included in review stages as its not relevant for others

canCurrentUserChangeMetadata (not per stage)

  • boolean
  • this is not specific to stage, so it can be outside of the stages array
  • reference implementation https://github.com/pkp/pkp-lib/blob/main/pages/workflow/PKPWorkflowHandler.php#L177
  • basically its checking canChangeMetadata for assigned users to the stage assignment (regardless of what stage they are assigned) and ROLE_ID_MANAGER can do always edit it. Thats my understanding, but please double check it from linked implementation.

currentUserAssignedRoles (per stage)

  • array of roleIds
  • stage specific, would be calculated for every stage
  • this already exist, but its not accurate as its fetching stage assignments twice, once filtered by stage and once for all stages and combines them together. Desired would be to get only the roleId for current stage

currentUserRecommendation - if I am recommend only editor (only in review stages)

  • this be null or object, based on whether I am recommendOnly editor and whether decision has been made (last decision is relevant)
  • relevant for review stages (ideally to include also internal one for OMP), so it makes sense to include it only in these stages
  • object shape could be: {'decision': 3, label: 'Recommend Revisions'}
  • reference for retrieving such decision - https://github.com/pkp/pkp-lib/blob/main/pages/workflow/PKPWorkflowHandler.php#L611C1-L612C1

recommendations - if I am deciding editor (only in review stages)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement:2:Moderate A new feature or improvement that can be implemented in less than 4 weeks.
Projects
None yet
Development

No branches or pull requests

2 participants