Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import improvements #28

Merged
merged 10 commits into from Feb 19, 2020
Merged

import improvements #28

merged 10 commits into from Feb 19, 2020

Conversation

@cziaarm
Copy link
Contributor

cziaarm commented Jan 8, 2019

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

@cziaarm

This comment has been minimized.

Copy link
Contributor Author

cziaarm commented Jan 9, 2019

Added fixes for #29 and #30 too

@wfyson

This comment has been minimized.

Copy link
Collaborator

wfyson commented Jan 17, 2019

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

This comment has been minimized.

Copy link
Contributor Author

cziaarm commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

cziaarm commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Collaborator

wfyson commented Mar 22, 2019

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

This comment has been minimized.

Copy link

photomedia commented Aug 20, 2019

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

This comment has been minimized.

Copy link
Contributor

dennmuel commented Aug 21, 2019

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

MicheleMorelli and others added 4 commits Aug 28, 2019
fixed issue caused by dataset misplacement
@photomedia

This comment has been minimized.

Copy link

photomedia commented on 788bca1 Feb 12, 2020

Thanks, @wfyson , if there is a new EPM (version 1.5.1), can it also be added to the EPrints Bazaar? http://bazaar.eprints.org/1102/? The latest version listed there is 1.5 modified 21 Mar 2019
I am having problems with Contributors of items imported from ORCID not showing up in the imported publication, and I am hoping that this update solves those issues?

@wfyson wfyson merged commit 3f51182 into eprints:master Feb 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

5 participants
You can’t perform that action at this time.