As a member of the support team, I'd like to decouple title transfers from resource resolution URL updates

As a follow-up to https://gitlab.com/crossref/issues/-/issues/1366, the support team and others have agreed that one way we can prevent similar issues in the future is to decouple how we, the support team, submits and processes title transfers and URL updates.

Currently, it is possible to transfer ownership of DOIs and update resource URLs in the same file. In practice, those two tasks are almost never requested of support in the same file.

Typically DOIs are transferred to new owners and then some time later, the new owner will update the resource resolution URLs. Given this fact, it seems preferable to decouple title transfers from resource resolution URL updates, so that we can avoid unwanted or inadvertent title transfers when errors are present in the fromprefix and toprefix header.

Typical title transfer request file:

H:email=support@crossref.org;fromPrefix=10.9786;toPrefix=10.5555
10.5555/testDOI4Z37ur
10.5555/testDOIJJ031c
10.5555/testDOI_nK8v5

Typical URL update request file:

H:email=support@crossref.org;fromPrefix=10.5555;toPrefix=10.5555
10.5555/testDOI4Z37ur	https://crossref.org/newURL

Other considerations/improvements:

I, Isaac, don't want to get too prescriptive in how this is done, but it would also be helpful if the URL update process, once decoupled, has a check in it that confirms all the DOIs in the URL update file are all owned by the same username. So, perhaps a new declaration in that header that confirms that all DOIs in the file are owned by a specific username to protect us from errors?

What

Separate the DOI change root super user update type in the admin tool into: 1) title transfer only and 2) resource resolution URL update only

Why

To avoid major problems like: https://gitlab.com/crossref/issues/-/issues/1366

How urgent

Moderately. Ideally ahead of January 2022, so we can learn the new process and ahead of beginning-of-year peak of these types of requests.

Definition of ready

• Product owner: @SaraBowman
• Tech lead:
• Service:: or C:: label applied
• Definition of done updated
• Acceptance testing plan:
• Weight applied

Definition of done

• Unit tests identified, implemented, and passing
• SONAR on merge request branch checked by tech lead
• SONAR on merge request branch checked by reviewer
• Code reviewed
• Available for acceptance testing via a staging URL, or otherwise
• Consider any impacts to current or future architecture/infrastructure, and update specifications and documentation as needed
• Knowledge base reviewed and updated
• Public documentation reviewed and updated
• Acceptance criteria met
  • AC 1
  • AC 2
• Acceptance testing passed
• Deployed to production

Prior to and during Backlog Refinement, consider the potential impacts this user story may have on the following areas:

• Billing/costs
• Internal documentation
• External documentation
• Schema
• Outputs
• Operations
• Support & Membership experience
• Outreach & Communications
• Testing
• Internationalization
• Accessibility
• Metrics, analytics, reporting

Additional details about the above items can be found here.

Notes