Currently, an unpublished draft dataset can be deleted with two button presses (cf. #660) with no option to recover a deleted draft dataset. This can lead to loss of work, e.g. when users have already entered and refined metadata over some time. Additionally, when the DOI registered for the draft has already been communicated or added to a paper it is not trivial to get a dataset with the same DOI again.
This has, unfortunately, happened to us and other Dataverse operators in the past (cf. #troubleshooting > Draft DOI - recover record). In our case, users (Depositors) wanted to delete a file and unintentionally deleted the draft dataset instead.
Having an additional safeguard for deletion of draft datasets could help prevent this. One way to solve this could be to prompt the user to type the DOI or DOI suffix of the dataset, similar to how GitLab (and similar platforms) handle deletion of projects.
Currently, an unpublished draft dataset can be deleted with two button presses (cf. #660) with no option to recover a deleted draft dataset. This can lead to loss of work, e.g. when users have already entered and refined metadata over some time. Additionally, when the DOI registered for the draft has already been communicated or added to a paper it is not trivial to get a dataset with the same DOI again.
This has, unfortunately, happened to us and other Dataverse operators in the past (cf. #troubleshooting > Draft DOI - recover record). In our case, users (Depositors) wanted to delete a file and unintentionally deleted the draft dataset instead.
Having an additional safeguard for deletion of draft datasets could help prevent this. One way to solve this could be to prompt the user to type the DOI or DOI suffix of the dataset, similar to how GitLab (and similar platforms) handle deletion of projects.