Feature Request/Idea: As a researcher, I'd like to be sure that the published dataset I tried to access has been deleted (destroyed)
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 564
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 29
Description
Overview of the Feature Request
What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
Curator, depositor, guest, superuser
What inspired the request?
A conversation with Kelly Stathis from DataCite about published datasets in Dataverse repositories that are then destroyed. She recommended that when users follow a DOI url of a dataset that has been destroyed, they're taken to a page that lets them know that the dataset was deleted, even if the page doesn't include any metadata about the dataset.
As of v5.13, users are taken to a 404 Not Found page, which is shown when any page doesn't exist, such as a Dataverse collection page.
For example, the DOI url https://doi.org/10.7910/DVN/2SYZDT used to point to a dataset in the Harvard Dataverse Repository that was destroyed. It now points to a 404 Not Found page:

What existing behavior do you want changed?
When users follow a DOI url that belongs to a published dataset that was deleted, they're taken to a page that lets them know that the dataset was deleted.
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 by tracing how Dataverse handles DOI URLs for datasets that no longer exist and how the current generic 404 page is selected. Review the affected routing and page-rendering entry points, then verify the behavior with a test covering a DOI for a destroyed published dataset. Done means users see a clear deletion notice rather than the generic 404 page.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100