-
Notifications
You must be signed in to change notification settings - Fork 447
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
Extend submissions REST API to support views and view counts #8887
Comments
pkp-lib: #9469 |
pkp/pkp-lib#8887 Refactor review assignments
pkp/pkp-lib#8887 REST API for dashboard views
pkp/pkp-lib#8887 Implement dashboard views
@asmecher, merged except reviewReport and pkp-docs, I don't have wright access to them. |
pkp/pkp-lib#8887 Document changes in the REST API and review assignments
@Vitaliy-1, both merged, thanks! |
@Vitaliy-1 This cause issue with only
|
@Vitaliy-1, can this issue be closed now? |
Describe the problem you would like to solve
As part of the new submissions list design (#8880), there are several new views. Each view will show submissions in a given state. For example, "No editor assigned" will show all submissions without a deciding editor assigned.
Describe the solution you'd like
Extend the REST API to support all of these views. There are lots of ways that this could be done. Here are some ideas:
This may be possible by adding query params to the existing submissions API for each view. For example, a
?needsEditor=true
query param.However, the number of query params might become very large. We may also encounter query "conflicts", for example consider combining the
needsEditor
param with theassignedTo
param for editor assignments:?assignedTo=1&needsEditor=true
. This would result in an "invalid" query, since both conditions can not be true. For that reason it may be better to consider more generic params, likewithCountEditors=1+
.Alternatively, it may be better to think of each view as a standalone thing. For example, maybe each view is a separate API endpoint, like:
/submissions/view/needsEditors
. This would result in more API code, but each handler method would be much simpler with fewer invalid conditions. It may also be easier to allow plugins to add views with this architecture.Also, for each view, we need to be able to get a count of submissions in that view. Because of the number of views, it will not be performant to make a separate API request for each view. We probably need a single API endpoint we can hit to get updated view counts. It may be worth considering caching this data in some way.
Who is asking for this feature?
This is required for #8880.
Additional information
When designing the solution, keep in mind that what views we have will change over time. An architecture that allows us to quickly add, edit or remove views will be best in the long-term.
The following views were settled upon after conducting user research.
MANAGER
,SUB_EDITOR
orASSISTANT
.MANAGER
orSUB_EDITOR
role except incomplete submissions.STATUS_SCHEDULED
status.STATUS_PUBLISHED
status.STATUS_DECLINED
status.For a user with the
MANAGER
role, each view will include all submissions, except the "Assigned to Me" view. For users with theSUB_EDITOR
orASSISTANT
role, they will only see submissions they are assigned to in one of those roles.One thing to note is that it should no longer be possible for editorial staff to see incomplete submissions through this list. In other words, all of these views should exclude incomplete submissions.
The text was updated successfully, but these errors were encountered: