As a member of the support team I want to be able to remove a claim between an ORCID ID and a DOI
If a publisher includes an ORCID in their metadata and the author has opted in to auto-update, an ORCID notification is triggered that adds the DOI to their ORCID profile.
If a publishers includes and ORCID that is new to Crossref, a notification is sent to the author's ORCID Inbox asking if they would like to opt in and add the DOI to their profile.
If the publisher has included an incorrect ORCID in their metadata, the wrong author will receive one of these notifications and will contact support to ask that they are disassociated from that DOI.
The main way to fix this is to ask the publisher to redeposit the metadata with the correct ORCID or no ORCID. This should delete the claim (@ifarley to test this.)
However this takes time and some publishers do not respond. Support should be able to remove the incorrect claim from our system and stop it from being made again in a redeposit. This would be done by creating a blacklist of ORCID IDs that should be blacklisted or disassociated with a specific DOI. This blacklist of DOI-ORCID pairs should be viewable and editable (add and remove) by support.
A list of DOI-ORCID ID pairs can be maintained by support on GitLab. This list will be checked before any future claims are made.
Design:
- The block-list will be a CSV file of ORCID, DOI pairs stored in a Git repository on GitLab. The code responsible for raising notifications will retrieve this and cache it.
- It's fine to cache this. Let's start with 24h for now?
- The size of the list is expected to be dozens rather than thousands. So it's fine to keep in memory.
- This can be unit-tested by mocking out the HTTP request.
- The URL will be supplied in a properties file.
- The repo will be open so no credentials needed.
- Log the decision along with the ORCID and DOI so we can instrument usage later.
Definition of done
-
Available via a staging URL or demonstrated with test DOI against real block-list in gitlab. -
Code reviewed -
Unit tests identified, implemented, and passing. Retrieval mocked out. -
Public documentation reviewed and updated -
Knowledge base reviewed and updated -
Changes to infrastructure
Testing
- Create a new DOI and test XML file and add your own ORCID (I used ORCID_test_withID.xml one
- Register the DOI
- Check your ORCID inbox for an alert, and grant permission for auto-update if you haven't already
- Create another DOI and test XML file with your ORCID (my file ORCID_test_withID2.xml
- Add this DOI and your ORCID to the blacklist following the instructions here
- Wait 24 hours (the blacklist is updated every 8 hours)
- Register the 2nd DOI
- Check ORCID inbox. You should not have received a notification
Prior to and during Grooming, consider the potential impacts this user story may have on the following areas:
- Internal documentation
- Operations
- Support & Membership experience
- Outreach & Communications
- Testing
- Metrics, analytics, reporting
Additional details about the above items can be found here.