gigascience / gigadb-website

Source code for running GigaDB
http://gigadb.org
GNU General Public License v3.0
9 stars 15 forks source link

The Mint DOI function should save the DataCite payload locally for auditing #372

Open only1chunts opened 4 years ago

only1chunts commented 4 years ago

User Story

As a curator I want the Mint DOI button to save the payload sent to DataCite So that we can audit the medata sent in case of dispute

Acceptance criteria

Given I am on the admin page for a dataset When I press the Mint DOI button Then the DataCite metadata is generated and sent to DataCite API And the DataCite metadata is saved in the dataset table And an entry linking to the payload is added to the curation log

Additional Info

Background Currently the Mint DOI button just creates an XML and send it to Datacite to be minted without saving a local, this is fine as long as it works, but when it fails it would be better if we could see the XML to assist with debugging.

Describe the solution you'd like Given that I am logged in as Admin When I click Mint DOI button Then DataCite XML is generated and saved to server somewhere, And that XML is used to mint DOI at DataCite (as currently happens)

Implementation

Resources

only1chunts commented 4 years ago

This could be done in combination with work in ticket #414

alli83 commented 1 month ago

And an entry linking to the payload is added to the curation log: what is needed? the all xml payload or some info?

only1chunts commented 1 month ago

as per the additional info above "Then DataCite XML is generated and saved to server somewhere" i.e. the entire XML payload generated by the Mint DOI button on that occassion.

alli83 commented 1 month ago

ok so I guess, you want a link and a modal with the all xml saved?

alli83 commented 1 month ago

of maybe under the Mint button, we could have a link to access the xml saved once it's done instead of having it in the curation log?

rija commented 1 month ago

Hi @only1chunts I think @alli83 meant the content of the curation log entry. We are already going to save the payload in the database, but does the curation log entry added when minting a DOI needs updating to somehow refers to the DataCite payload? I don't think it's a good idea to put the full payload in the curation log entry as it can be quite big. and we don't want to click on a link that will load the XML in the browser because and error will be thrown as the XML doesn't have stylesheet anwyere.

what we could possibly do is trigger the download of a file containing the payload from a link in the curation log entry

Alternatively we do nothing and you make queries to the database when you need access to the payload?

only1chunts commented 1 month ago

my expectation was as per the acceptance criteria "And an entry linking to the payload is added to the curation log", i.e. a link that will download the payload for viewing.

only1chunts commented 1 month ago

of maybe under the Mint button, we could have a link to access the xml saved once it's done instead of having it in the curation log?

it needs to be in the curation log so that its in the time line and can have multiple versions if required.

alli83 commented 1 month ago

@only1chunts But if we have to keep multiple versions, does that mean it has been minted several times? So If I understand it well, we need to keep a history of the different minting actions. If that's the case, it's changes the way we save things in the database.

update: imho, I'm wondering if there's a problem with the current approach. the dataset can still be modified event at the final step which is "published". So how do we know if the xml (dataset in xml format), is up to date or not? e.g DOI is minted -> we save the xml. but maybe later, someone is going to modify the dataset, so the xml would be outdated. Also the log can be updated, I can't have a link in the log. I think the best approach would be to have a link below the mint button (download the dataset as xml).

Could you please confirm this point? Thanks