Repository navigation
Add use cases for dataset curation status and submit for review #493
Description
Overview of the feature request
Add public use cases for the existing Dataverse curation-status APIs so the SPA can support the same label selection, removal, and history functionality as JSF. Curation labels are configurable tracking values. Changing a label does not submit a dataset for review, return it to its author, or publish it.
Also, add an use case of Submit for Review for anonymous user to submit the dataset to review.
What inspired the request?
The frontend's ChangeCurationStatusMenu currently opens the not-implemented modal. Its allowed labels come from hard-coded values in DataverseInfoJSDataverseRepository.getExternalStatusesAllowed(). The frontend needs the effective labels for each dataset and reusable client methods for the real API operations.
What existing behavior do you want changed?
Expose these operations through the package's public API, following the existing use-case → repository interface → repository implementation pattern. Consumers should not need direct HTTP requests or imports from internal dist/ paths.
Any brand new behavior do you want to add to dataverse-client-javascript?
Proposed use cases (names can follow project conventions):
| Use case | Backend API |
|---|---|
GetAllowedDatasetCurationLabels |
GET /api/datasets/{id}/allowedCurationLabels |
GetDatasetCurationStatus |
GET /api/datasets/{id}/curationStatus |
GetDatasetCurationStatusHistory |
GET /api/datasets/{id}/curationStatus?includeHistory=true |
SetDatasetCurationStatus |
PUT /api/datasets/{id}/curationStatus?label={label} |
DeleteDatasetCurationStatus |
DELETE /api/datasets/{id}/curationStatus |
SubmitforReview |
POST /api/datasets/{id}/submitForReview |
Acceptance criteria
- Implement and publicly export all five use cases and their models.
- Extend
IDatasetsRepositoryandDatasetsRepository, with response mapping as needed. - Add unit tests for delegation, response normalization, history/removal records, and error propagation.
- Add integration tests for numeric and persistent IDs, query encoding, allowed-label retrieval, set/read/change/remove/history, and forbidden or invalid operations.
- Verify a status change does not change review locks or publication state.
- Document required configuration (
:AllowedCurationLabelsand effective label-set selection), publisher permissions for mutations/allowed-label reads, and configurable visibility for status reads. - Update
docs/useCases.mdand the[Unreleased]changelog; pass build, type checking, lint, and relevant tests.
This issue covers client wrappers for existing curation-status APIs. Frontend components, administrator label-set configuration APIs, submit-for-review, and return-to-author use cases can be tracked separately.
Any open or closed issues related to this feature request?
No matching curation-status issue was found. #447 concerns linked review datasets, which are separate from curation labels and their history.
References:
Activity
[-]Add use cases for dataset curation status and history[/-][+]Add use cases for dataset curation status and submit for review[/+]