Inconsistent behaviour of dataset delete API - #12332
Conversation
This comment has been minimized.
This comment has been minimized.
753818d to
153ec4c
Compare
This comment has been minimized.
This comment has been minimized.
153ec4c to
09a31f7
Compare
This comment has been minimized.
This comment has been minimized.
09a31f7 to
f83ba61
Compare
This comment has been minimized.
This comment has been minimized.
106b4dc to
7a441b4
Compare
This comment has been minimized.
This comment has been minimized.
7a441b4 to
b0124fb
Compare
This comment has been minimized.
This comment has been minimized.
b0124fb to
81859f7
Compare
This comment has been minimized.
This comment has been minimized.
81859f7 to
fbe0852
Compare
This comment has been minimized.
This comment has been minimized.
fbe0852 to
72bf6b7
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
From QA: This appears to now work as discussed in the issue, which I think continues to be inconsistent with the documentation. When published version(s) and a draft exist, the Delete Unpublished Dataset API just deletes the draft and doesn't fail because the dataset has been published.
I'd suggest one of two changes:
- make this only work if there is only a draft, or
- adjust the docs to make it "Delete Unpublished Dataset Changes" and explain it removes a draft version (and metadata changes and deletes any files added in the draft) which results in deletion of the dataset if there are no published versions.
If it always deletes a draft (if one exists) - i.e. option 2, it's more of a duplicate of the DELETE /api/datasets/versions/{versionId} call (which, despite the signature, only works on drafts), so limiting this call to truly deleting unpublished datasets only might be more useful, but it's a bigger backward incompatible change. Option 2 also results in redundant code if there's no clean-up.
I'm not sure what the process should be to make a choice - perhaps just standup discussion?
Also - the PR doesn't update the change log to note the backward incompatibility (for superusers only at present).
Otherwise - the api does remove the draft, delete draft only files and not files in published versions, does redirect superusers to the destroy api as intended.
|
This comment has been minimized.
This comment has been minimized.
2 similar comments
This comment has been minimized.
This comment has been minimized.
|
📦 Pushed preview images as 🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name. |
|
We discussed this yesterday and I suggested to @qqmyers that he could make a fresh pull request show how he thinks the APIs should change. He said he would but no rush! As discussed, this is not a must have. |
|
#12639 extends/replaces this PR. |


What this PR does / why we need it: API call of delete Dataset does not match what has been documented. Superuser must use /destroy to delete a released Dataset. Delete Dataset API should only work for "Draft" datasets.
Which issue(s) this PR closes: #11253
Special notes for your reviewer:
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Is there a release notes update needed for this change?: Included
Additional documentation: