I would like to know if there are any special steps and/or considerations to take into account if, for a given journal, on a single-journal instance, we wish to change the ORCID API settings.
We would like to change from a public ORCID API key generated and obtained by one of the editors, to a member ORCID API key our Library manages for our institution. Since this is a journal in production where most of the authors have registered with their ORCIDs and have linked their ORCIDs, I would like to make sure that this change is smooth and seamless knowing there are articles at different stages of the editorial process. Are the orcidAccessToken and orcidRefreshToken stored in the DB for authors and users independant from the API key?
My understanding is that records from already published articles will not be pushed to ORCID profiles, since this needs a specific autorisation of the author/co-author on the ORCID side (I guess orcidAccessScope in the DB) and moreover the transfer is done at the time of publishing. Is that correct?
Also, I am already aware that the credentials information can be in the config.inc.php file to remain secret.
Any information will be welcome.Thank you in advance.
I find your question very interesting since I am also working with the ORCID plugin (not an expert though).
My concern in this scenario would be the different access scopes.
For every user, who has connected via the public API, the /authenticate scope has been saved in the database as orcidAccessScope. Within this scope, the plugin cannot push articles to ORCID profiles.
The access and refresh tokens are independent from the API credentials in the sense that for most calls to the ORCID API you only need the tokens.
Considering this, it should be possible to switch to the member API credentials without accidentally pushing articles to the users ORCID records as long as the access tokens you have already stored in your database stay the same.
The problem I see however, is that after switching to the member API, you won’t be able to push anything to the ORCID profiles of users who have connected using the public API before, because the DB still has the /authenticate scope stored for them. The member API uses the /activities/update scope to push articles. I think these users would have to authorise again against the member API to get the /activities/update scope and the corresponding access tokens.
Already published articles should not be affected by this change.
Thank you @lenare for this very instructive answer that do help me tremendously. Yes, I see what you are talking about with the already registered users with the public API that, I’m afraid, will have to authorize again against the new member API. I will run a few tests with public/member keys in the sandbox and come back to report here.
@Marie-Helene
I totally agree with @lenare s detailed comment.
If authors want to add the article to their orcid records, the currently available best thing you can do is to delete the orcid ID and then ask them to re-authorise.
Also note that the Metadata is pushed to the orcid profile at publication, so you need to click unpublish and re-publish again to trigger the publishing.
I’m following up after a delay, sorry.
If it can be helpful for someone:
Here’s what I did:
Activated the premium API member key.
Removed the few occurrences of ‘orcidAccessScope => /authenticate’ from the user_settings table to force a possible reset of authentication.
For the articles in progress, there were no authors with an ORCID number in their user profile, which suggests that editors will be able to request (manually or automatically during production phase) authors to authenticate their ORCID number according to the new scope (/activities/update).