search

eprints / orcid_support_advance

ORCID Support Advance plugin
1 stars 6 forks source link

import improvements #28

Closed cziaarm closed 4 years ago

cziaarm commented 5 years ago

fixes #27 and #4 also some render bugs regarding new buttons on import page

cziaarm commented 5 years ago

Added fixes for #29 and #30 too

wfyson commented 5 years ago

Hi @cziaarm I've just been having a look at this and came across an issue that leads to some slightly odd behaviour. By reading a BibTeX citation during the import process we can fill the creators field with author names, but not emails or ORCIDs. Then later on during the import process we see that creators have been filled in and so we don't add the current user. As a result no ORCID (or put-codes) get added to the record even though we've just imported from orcid.org.

I think this problem ultimately arises as a result of ORCID's handling of BibTeX, and can be resolved by the user adding their appropriate Creators ID to the creators to copy over the ORCIDs from their connected profiles, but it does just seem odd that we're importing from orcid.org but no ORCIDs are automatically imported... Also it won't occur when ORCID provides contributor elements with this information, but I'm not sure how those get added to an orcid.org work - they're not extrapolated from a BibTeX import at least and they can't be manually added.

I'm happy to merge this still, but just wanted to flag up the issue. I'm not sure there's much that can be done about it though unfortunately!

cziaarm commented 5 years ago

hold off with the merge, as I've found something new and odder in which the importing users orcid (and email/id) is assigned to all the creators when imported....

cziaarm commented 5 years ago

Hi @wfyson,

63593a7 fixes the problem I was having so that if we are importing authors who have a verified orcid in the repo but are not the importing user, they get their own orcid and not the importing user's.

With the put-code stuff, I am not 100% sure what should be happening, but I think I can see what is.

The BibTex parsed data will indeed add some creators (with only names) however this will get overridden by the orcid contributors:

here and here and the bits in between.

In those bits in between the putcode is added

here and here

If you uncomment lines this and that you'll see that the put code is in place for the importing user when the value is set, but after the commit it has vanished!!

Which leads me to believe that in this here trigger the putcodes are being unset again...

Thing is, as I said at the top, I'm not 100% sure what should be happening so I'm thinking that this would be a good place to stop tinkering and let you explain the whole putcode thing :)

R

wfyson commented 5 years ago

Hi @cziaarm , Sorry it has taken me so long to get back to you about this. You're right about the BibTeX import issues, with the putcode being added, but then lost with the later commit. Ultimately the ORCID is still dependent on there being a Creators ID value to connect the creator to a connected user profile. Without that we can't have an ORCID and so we can't have a putcode either. As mentioned previously I don't think there's a way around this just yet without a means for storing some provenance information to provide other methods for verifying an ORCID's presence in the creators table.

photomedia commented 5 years ago

I'm testing out this plugin on our development server and the ORCID Sandbox, and I am finding that when I "Import from ORCID" publications where I am a co-author, only my name is listed in the creators for the imported items. There is no errors or warnings, and the resulting publication metadata in the repository now looks like I am the sole author. Is this the issue that is being addressed by the pull request described in this thread?

dennmuel commented 5 years ago

Hi @wfyson and @cziaarm

I kinda lost track here, so bear with me and correct me while I try to get it right...

The first problem is, that if the record on the orcid.org profile does not contain the orcid id - because the record has been added manually - then neither orcid id nor putcode are imported to eprints (naturally). This could be circumvented, if the orcid.org user had his/her e-mail-adress within the orcid work - however most users probably don't and even if so, this would cease to work once #21 would be implemented. We can't do orcid work, if we don't have an orcid - simple as that. So in order to get at least one orcid+putcode into the repo, we could check if none of the contributors has the orcid id of the importing user, in that case add the importing user as well and display an alert, that the contributor metadata would need some correction: the e-mail-adress must be added to the contributor with orcid id and the duplicate contributor without must be removed.

The second problem is, that even if we have an orcid+putcode, it gets unset by the pre-commit trigger. So I'm wondering, if we can't just set the orcid_update property like we do in the export, so that the whole orcid+putcode validation doesn't happen? (This would be necessary for my solution suggested above, anyway.) This is an update from orcid.org and IMHO it's not necessary for the trigger to validate the orcid ids against the repo users, because as you've said: orcid ids cannot be added manually to orcid.org records and thus have already been authenticated in one way or another. However, again, next time the eprint gets modified manually, the email adress must be added, so that the trigger can validate the orcid then.

@photomedia , I guess in your case the import sets the importing user as a creator, if it does not find any other person here. Might very well be adressed in the course of this issue.

Finally, I would also like to point to this commit in a PR of mine where I fiddled with the contributor roles in the import. If this gets merged eventually, it might require some adjustment to Rory's work in this.

Best regards