Fix the current behavior when using the :latest tag in getVersion API calls for deaccessioned datasets and unauthenticated users

[GPortas]

Overview of the Feature Request

The recent introduced changes on #10191 have introduced an unexpected behavior on the Datasets getVersion API endpoint.

Currently, we can obtain a deaccessioned dataset using :latest-published tag. Example:

curl -X GET "https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/:latest-published?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true"

Or using the numeric tag (e.g. 1.0). Example:

curl -X GET "https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/1.0?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true"

But we obtain a 404 error if we use :latest tag:

curl -X GET "https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/:latest?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true"

The solution will involve modifying GetLatestAccessibleDatasetVersionCommand to handle "checkPerms" as an input parameter. This param should be set to false when the command is called from the getDataset endpoint with query params includeDeaccessioned=true and excludeFiles=true.

What kind of user is the feature intended for?
API User

What inspired the request?

• Frontend weekly meeting: https://docs.google.com/document/d/1DkKqcFEWw6M9wF78irsdLISSbkhZOIvmoBx6ir8K1gA/edit#heading=h.3dy6vkm
• Modify getDataset repository API call to use 'excludeFiles' parameter dataverse-client-javascript#112

What existing behavior do you want changed?

Support :latest tag in getVersion endpoint calls for deaccessioned datasets and unauthenticated users

Any brand new behavior do you want to add to Dataverse?

None

Any open or closed issues related to this feature request?

• Modify getDataset repository API call to use 'excludeFiles' parameter dataverse-client-javascript#112
• return deaccessioned version of dataset in more cases #10191

[jp-tosca]

I have a follow-up regarding this issue @GPortas:

#10164 mentions that the API could not access a deaccessioned dataset if the user doesn't have edit permissions which require providing credentials.

In 6.1 all these 3 will fail:

• Specific version

http://demo.dataverse.org/api/v1/datasets/:persistentId/versions/1.0?includeDeaccessioned=true&includeFiles=false&persistentId=doi:10.70122/FK2/IXMERS

• Latest

http://demo.dataverse.org/api/v1/datasets/:persistentId/versions/:latest?includeDeaccessioned=true&includeFiles=false&persistentId=doi:10.70122/FK2/IXMERS

• Latest published

http://demo.dataverse.org/api/v1/datasets/:persistentId/versions/:latest-published?includeDeaccessioned=true&includeFiles=false&persistentId=doi:10.70122/FK2/IXMERS

All these 3 will work if you provide credentials, which probably shows that this behavior was not introduced in #10191 but part of the existing issue.

The changes from #10191 address the issue from #10164 for these 2 test cases:

• Specific version

https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/1.0?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true

• Latest published

https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/:latest-published?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true

But failed to address this one:

• Latest

https://beta.dataverse.org/api/v1/datasets/:persistentId/versions/:latest?persistentId=doi:10.5072/FK2/UBKVYE&includeDeaccessioned=true&excludeFiles=true

I will apply a similar fix so ":latest" is also publicly available.