Give admins the ability to reset/request DOIs for Items/Theses where they are missing or broken

[mbarnett]

User Story

As a Developer, I would like to get out of the business of manually fixing issues with DOIs.

Context

Occasionally (phase of the moon? random server reboots? timeouts on datacite's end? idk. I suspect we might be hitting some kind of rate limit on Datacite's end, as it seems to happen to things that are ingested in a large batch...) items are getting stuck with their DOI state in :unavailable or :unminted. Dropping the state and manually touching off a call to handle_doi_states has resolved all of these so far, but I've seen 4 or 5 such issues come to me since May, and having me do this manually is an expensive way to solve this problem.

Pitch

Let's just create a button in the interface, only available to admins, on Items and Theses, that resets the state machine and re-requests the DOI, so that helpdesk and metadata stakeholders can fix this themselves rather than need our assistance.

[ConnorSheremeta]

Clicking on the button/link should call remove_doi and the subsequently call handle_doi_states

These can be called from within a method in a doi_controller in the admin directrory.

The link/button can be made a partial and can be rendered in _item.html.erb along with _thesis.html.erb .

Screenshots of mock-ups:

1. Under an admin panel

If we think three will be more things in here in the future this might be the way to go? I think it would be nice for all admin abilities to be in one spot.

---

2. As a button below the DOI

This might make the most sense as it is right below the 'broken' DOI

---

3. As a link beside the DOI

This is not a nice looking as a button in my opinion but is still a valid approach

Thoughts @mbarnett ?

[ConnorSheremeta]

I'm also thinking there should be a page refresh so the updated DOI is displayed

[mbarnett]

I don't think we want to call remove_doi, as that will tombstone the existing DOI and mint a brand new one, which isn't generally the issue people are running into.

The main thing I've seen is that we end up with Items/Theses with no DOI and their doi_state stuck in not_available – because the original call to the data cite API didn't return correctly for whatever reason.

So probably we want to only render the button in those cases (state is not_available, there is no DOI, and probably it's been greater than X minutes from creation, since right after ingest the button would appear until the background job finishes, otherwise?), to allow admins to re-request an initial minting. Having the button call handle_doi_states should suffice to resolve that issue (and we can always add more buttons to handle other issues if they crop up, with appropriate warnings if they're destructive).

UI-wise the the first option is probably best if we're assuming most of the time this is intended to handle cases where there is no DOI on the Item/Thesis.

edit: oh, and I'd probably put the DOI partial into show, like how we do the files sidebar: https://github.com/ualbertalib/jupiter/blob/integration_postmigration/app/views/items/show.html.erb#L42 rather than put it in the item and thesis partials, which just contain the main content. Otherwise solid plan 👍