As a member and registrant of ORCID metadata, I'd like ORCID-related errors to return the DOI in the error message

One of our members has requested that ORCID-related submission errors be tweaked to include the DOI for which the error is being returned. They claim that is difficult to automate their process without a DOI returned in the error.

Here are a few example submissions:

1504113223

<record_diagnostic status="Failure" msg_id="45">
      <doi>DOI not found</doi>
      <msg>Error in Journal Article (Author ORCID): ORCID "https://orcid.org/0000-0003-0859-4004" has invalid checksum</msg>

1477036222

 <doi>DOI not found</doi>
      <msg>Error in Journal Article (Author ORCID): ORCID URL "0000-0003-2571-1450" has duplicates in contributor list</msg>
   </record_diagnostic>

What

Incomplete information in the error message returned for ORCID-related problems with submissions.

Why

Easier to troubleshoot submission errors when the failing DOI is included in the message.

How urgent

Low to moderate.

Definition of ready

• Product owner: @bvickery1 / @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
  • ORCID-related errors return the DOI in the submission log error message
  • Respond to and close community forum - https://community.crossref.org/t/enable-to-v2-api-access-endpoints-for-members-using-custom-software-and-more-intelligent-submission-reports-to-diagnose-easily/1365/4
• 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