Incorrect storage of ORCID's "put code" cause unintended deposit updates

[taslangraham]

Describe the bug
The ORCID documentation (here & here) mentions that a put code is used to identify a single work item withing ORCID.

Put codes are short numeric codes that reference a particular item on the ORCID record. You use the put code with the API calls to update, delete or read a particular item (as opposed to a summary of items.)

When you post an item to a researcher's record, the API response will contain the put code for that item. You can store the put code to use it later if you need to read, update, or delete that item.

However, our current implementation stores the put code on the review(user)/author object via settings table instead of the individual work item (submission or review work). As a result, we do not have the put code for all items. This creates a problem, particularly when depositing new review work - a check is made for an existing put code on the reviewer(user) object, and if one is found(due to a previously deposited review work) it updates that record instead of creating a new entry.

https://github.com/pkp/ojs/blob/de0da4acfd19e8640ed777930f8beb060fc309c9/jobs/orcid/DepositOrcidReview.php#L74-L78

                if ($putCode = $reviewer->getData('orcidReviewPutCode')) {
                    $uri .= '/' . $putCode;
                    $method = 'PUT';
                    $orcidReview['put-code'] = $putCode;
                }

N.B: The logic for deposition submission work does not make use of the put code stored on the author's object.

To Reproduce
Steps to reproduce the behavior:

1. Ensure ORCID is enabled in the application, along with test ORCID accounts
2. Add ORCID to the profile of a Reviewer
3. Request review from the reviewer for 2 submissions
4. Log in as the reviewer, and respond to both review request
5. Log in as Editor, confirm one of the reviews, and thank the reviewer
6. Log into the Reviewer's ORCID account and notice that there is one new entry under the Peer review section
7. Log in as editor again, confirm the second review, and thank the reviewer
8. Log into the Reviewer's ORCID account again and notice that the new review work was not added

What application are you using?
OJS 3.5

PRs
pkp-lib: #10776
ojs : pkp/ojs#4580
omp: pkp/omp#1799
ops: pkp/ops#836

[taslangraham]

After further reviewing the issue, I believe the way we are currently storing the put-code for submissions (via author settings) is fine and will work as expected. However, the method for handling reviewers' put-codes needs to be changed.

I have two ideas in mind to address this:

1. Introduce a review_assignment_settings Table

For the review assignments, we could create a review_assignment_settings table where we store the put-code for each review

2. Introduce an orcid_records Table

Alternatively, we could introduce an orcid_records table that will store all put-codes related to both authors and reviewers. This table would have the following structure:

Column Name	Type	Description
orcid_records_id	int	primary key.
assoc_type	string	ASSOC_TYPE_REVIEW_ASSIGNMENT or ASSOC_TYPE_AUTHOR.
assoc_id	int	The ID of the review assignment or author.
put_code	int	The ORCID put-code associated with the record.
user_id (optional)	int	User this record is related to.

With this setup, we would store all put-codes related to both author and reviewer assignments in one central location.

Additionally, we could introduce an optional orcid_records_settings table to store more information about each ORCID deposit, if necessary. However, I don't see an immediate need for this.

I'm in favor of option 2 (without orcid_records_settings table) as it would allow us to keep all put-codes in one place.

@ewhanson let me know your thoughts on this, please.

[ewhanson]

Hey @taslangraham, thanks for looking into this further. I think in this case, creating a review_assignments_setitngs table would be a better way to go.

If we do want to refactor the way ORCIDs work to have their own tables, I'd prefer to not do that so close to a release. I think option 2 is generally a good idea and something we can look into with future work on the ORCID functionality. As a first step towards that, you could add the information you've put together here and add it to a Github discussion (rather than an issue) as I think this would have benefits for some of the future work we've talked about for the ORCID functionality as well.

[taslangraham]

@ewhanson Apologies for the delay. I've added the discussion here.

[taslangraham]

Ready for review @ewhanson. I've added the PRs to the issue description