Note, as discussed last week, in addition to the API call that deletes a lock, also implemented API calls to look up/check locks, and to lock datasets (as DELETE, GET and POST end points).
(plus the IT tests for these APIs)

Pull request #4986 looks good to me. Good docs. Happy to see tests. I moved it over to QA but I did leave this comment in my review: "The only thing that gave me pause is that no authentication seems to be necessary to check for locks but I don't think this would cause much harm. Approved."

Agree with @pdurbin about not much harm, but technically it could allow a user to learn info about a draft dataset which they shouldn't know exists.

@scolapasta From the docs, this info would appear to be retrieving the lock type of an unpublished dataset for which the user already knows a DOI - authentication should still be necessary to retrieve metadata or files; so I'd agree that this isn't likely to be a problem.

why not just tie this to view permissions?

@kcondon and I noticed that the PDF is failing to build for the guides using the "guides.dataverse.org-rfi" job in Jenkins. The branch was 31 commits behind the "develop" branch...

... so in 3e611e0 I just merged the latest from "develop" into the "4926-unlock-dataset-api" branch so we can try again. This failure to build the PDF was first noticed for #4973 which was also a bit behind "develop". "develop" is building the PDF fine with the same job so hopefully this fixes it.

• @landreev One quick issue, when deleting the InReview lock, the dataset card needs to be reindexed, otherwise it shows InReview when it is not.

Another issue: when deleting all locks on a dataset that has multiple locks, it deletes one, then throws a 500 error.

• Another minor issue, a typo in the manual lists lock type pidRegistration in the example when it should be pidRegister

Will check in fix for the indexing part (and the typo fix in the guide) momentarily.

Fixed: reindexing; concurrent modification exception w/ multiple locks; typo in the guide.