Move ORCID functionality into core application

[ewhanson]

The ORCID functionality currently exists as part of the OrcidProfilePlugin. This issue is to track the work needed to move ORCID functionality entirely within the core application.

This includes:

• OJS ORCID functionality moved
• OPS ORCID functionality moved
• Basic (public API) ORCID functionality added to OMP

[ewhanson]

Hey @bozana, here is the initial pass at this work. Could you have a look and let me know what you think before I clean it up/proceed with implementing this for OMP and OPS? Thanks!

PRs:

• pkp-lib: pkp/pkp-lib#9771 Move ORCID functionality into core application #9818
• ui-library:pkp/pkp-lib#9771 Move ORCID functionality into core application ui-library#339
• ojs: pkp/pkp-lib#9771 Move ORCID functionality into core application ojs#4221
• omp: pkp/pkp-lib#9771 Move ORCID functionality into core application omp#1570
• ops: pkp/pkp-lib#9771 Move ORCID functionality into core application ops#684

[bozana]

Hi @ewhanson, I went through the code. All looks good. I haven't tested it. There are mostly smaller comments to consider and a few questions (eventually to think about).
I think I had difficulties to understand classes/orcid/actions/AuthorizeUserData.php and classes/orcid/actions/VerifyAuthorWithOrcid.php -- not the code itself, but how ORCID is functioning there, what everything is how needed to be... I suppose I would need to read and dive deeper into ORCID documentation. However, if you find a way to make it easier for other developers to understand it, e.g. by providing a link to that ORCID API or documentation, it will be great, but no too much worries about it :-)
Thanks a lot, great work!

[bozana]

These changes needs to be consider once #699 is merged: jyhein/orcidProfile@a35e900.

[ewhanson]

Hey @bozana, this is finally ready for a review! Would you be able to have a look (complete PRs referenced above)? There are still a few things left to do, but I'd prefer to get these large set of changes merged and complete the rest as separate PRs (outlined below).

Still TODO:

• OpenAPI documentation for ORCID API endpoints
• FieldOrcid modal closing parent modal bug (in ui-library)
• Settle on pattern for submitting ORCID settings form with incomplete required field when disabling ORCID functionality
• Add additional integration tests

Thanks!

Edit: I've also asked if @jardakotesovec could review the ui-library portion.

[jardakotesovec]

@ewhanson Can you provide some screenshots or overview what orcid functionality this brings?

I see there is orcid setting form on journal/site level.

And than OrcidField is used on contributorForm, which makes it possible to request orcid verification from contributor in Publication section.

How about if user wants link their account to orcid in their profile or during submission? Thats to come later?

[ewhanson]

Hi @jardakotesovec, thanks for having a look. Happy to provide an overview/share some screenshots.

For the most part, this is a direct port of existing plugin functionality into the core with a few tweaks.

Here are the details:

Settings

• The Orcid settings can be set on a journal-by-journal basis or can be set globally at the site level.
• The site level settings take precedence over the journal level settings. If the site level settings are enabled, the ORCID functionality cannot be disabled at the journal-level and the client id, client secret, and API type are locked.
• The journal's city, whether to send emails to authors, and what level of error logging can still be configured at a journal level even with the site-level settings enabled.
• One major change from the plugin version: the site-wide settings were previously items added to the config.inc.php file and required server access to add/change. This is now handled entirely within the UI of the site.

FieldOrcid

Sending emails to authors requesting they connect their ORCID can happen in a few different ways/places.

• The most common way for actual users will likely be via a job that's triggered at various points as a submission moves through the workflow process (e.g. on being accepted, on being published, etc.).
• It can also happen via the contributors field (this is where the FieldOrcid component was introduced. This replaces a set of checkboxes that would trigger either the request for ORCID validation or removal of ORCID from a contributor as part saving the contributor form. When completed by the author in question, the ORCID will be associated with the author record attached to the submission.
• Users can also verify their ORCID to their user account under their user profile settings (under public). This does not use the FieldOrcid component as this form is not using any of the newer form components/Vue. In the future, it would be nice to unify the use of the FieldOrcid component for this, but in the mean time, the existing approach from the plugin is used.

OJS 3.3 ORCID plugin contributor ORCID request view

OJS 3.5 FieldOrcid button in contributor form

Styles

• Previously the plugin had its own CSS file that was included in various places. This is currently here in pkp-lib: https://github.com/ewhanson/pkp-lib/blob/orcid/styles/orcid.less and it needs to be included in the frontend theme like this: https://github.com/ewhanson/ojs/blob/bc958e2945389a78897fee05a86e68473f698d69/plugins/themes/default/styles/index.less#L23-L24
• Not being able to find this file in pkp-lib from the ui-library also seems to be breaking the chromatic builds, but I'm not sure what can be done about that.

Other functionality

• The other primary uses of the ORCID functionality require access to the ORCID member API and involve adding works/contributors back to a user's ORCID profile. This doesn't involve any UI and happens automatically when configured when a submission is published or when a reviewer is thanked.

---

I think that about covers it. Let me know if anything here is unclear or you have any quesitons!

[jardakotesovec]

@ewhanson Thats great overview, thank you!

The most common way for actual users will likely be via a job that's triggered at various points as a submission moves through the workflow process (e.g. on being accepted, on being published, etc.).

Can you explain this one in more detail? Does it mean that would receive email at some point (accepted/published) that would ask them to verify orcid?

[ewhanson]

Hey @jardakotesovec,

Can you explain this one in more detail? Does it mean that would receive email at some point (accepted/published) that would ask them to verify orcid?

Yes, I actually just checked and I believe the "on publication" aspect needs to be reimplemented (I think it got lost in some refactoring), but the email is sent when the submission is accepted or skips review. You can see that code here: https://github.com/ewhanson/pkp-lib/blob/orcid/classes/observers/listeners/SendAuthorOrcidEmail.php

Edit: Though now that I think about it, I think I'm confusing requesting verification from authors and attempting to deposit works with a user's ORCID profile. I'll review this and make sure it's all reflected in the documentation/consider if it should be added if it wasn't present in the plugin functionality.

[ewhanson]

Merged!

[bozana]

@ewhanson, do we need to open a new issue for the further task(s) we still need or would like to do? E.g. OpenAPI documentation for ORCID API endpoints, consider the comments from the PKP-ORCID Working Group, what to do with old and not verified ORCID iDs in the DB (and consider import/export regarding this), double check/improve the language for some locale keys, e.g. orcid.verify.duplicateOrcid and orcid.verify.duplicateOrcidAuthor, could we provide a solution for a work to be pushed after it is published?... -- those are I know we had on the list, but I am not sure any more about their status, maybe some are already solved...
Thanks a lot!