Inconsistent behaviour of dataset delete API
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 564
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 29
Description
While testing the dataset delete API, I just noticed the following behavior, which was unexpected to me:
When logged in as a superuser, and then calling the delete API on a dataset with exactly one published version and no draft currently existing, the request seems to be automatically "upgraded" to a destroy action. The request succeeds and the dataset is deleted.
I expected the request to fail, since the delete API is not meant for deleting published datasets (at least according to the docs where the API is titled "Delete Unpublished Dataset" and the destroy API exists, which is in contrast meant for deleting published datasets as a superuser).
What makes the behavior even more confusing to me, as soon as more than one published version exists, the delete API always fails even when I'm a superuser (message: This is a published dataset with multiple versions. This API can only delete the latest version if it is a DRAFT).
When not logged in as a superuser, everything works as I expected (delete API succeeds for drafts but fails for published versions).
Here's the related code: https://github.com/IQSS/dataverse/blob/f4380eafe647cc43b2f507f74123c7d9112c32c8/src/main/java/edu/harvard/iq/dataverse/api/Datasets.java#L278-L287
And my question: Is this intended behavior? If yes, I think the special case (superuser + exactly one published version allows delete API to succeed) should be documented in the API docs.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the delete API branch in src/main/java/edu/harvard/iq/dataverse/api/Datasets.java at lines 278-287, then compare its handling of a single published version with multiple versions and with the destroy API. Check the native API documentation linked in the issue and existing API tests if present. Done means either the behavior is clarified and documented or the inconsistent superuser case is corrected with coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100