Doi integration

Custom DOI Suffix Feature Integration

This feature branch implements the custom DOI suffix registration feature in the Hack4Impact PRD. Several of Kotahi's components were modified in implementing this feature.

Frontend

Changes were made to the frontend to support custom DOI suffix validation in several places. First, form TextFields were given a radio selection to turn on "DOI Suffix Validation," which requires the text field have a DOI suffix that isn't currently registered as its value. This field setting is supported in both the submission and decision forms.

Changes were also made to the frontend to support custom DOI suffix validation errors in the publishment phase. Upon clicking publish, if DOI's are already registered and can't be registered now, the request will fail with the error message displaying on the frontend. In addition, before publishment, a list of the DOIs to be registered will be shown to the user to better understand the registration flow of their current research objects.

GraphQL/API

Changes were made to the GraphQL api to move certain data from the backend to frontend in different parts of the UI. First, the validation of form fields mentioned in the above section was implemented through a GraphQL query that validates DOI suffixes. Second, a GraphQL query was implemented to return all DOIs to be registered from publishing an article. This is used in the publishment section of the manuscript control panel to display all DOIs to be registered.

Backend/Crossref Registration

In the backend, changes were made to use custom DOI suffixes from either the submission or decision forms. Logic was also added to validate that these DOIs (with custom suffixes) do not already exist. If they do, an error is thrown. The custom suffixes are persisted through all relationships in the research object data objects. Custom DOIs are implemented for both the preprint and standard workflows.

Docs/FAQ

In making changes to the form fields to support custom DOI suffixes, several new internal names for form fields are now referenced in the backend. These new fields are tracked in the FAQ.md file, alongside the existing fields for both the reviews and article publishment types.