Service: Fix bug where contributor email disappears

[ValentinFutterer]

Description

Bugfix

What does this PR do?

#128 introduced the fetching of ORCID-emails on Contributor create or update. The fetched email was alaways used instead of the current one, leading to it being overwritten - most likely with null.
Now the ORCID email is only used when no other email is present (this leads to ORCID email updates not being picked up by the tool, but this should not be a big problem in my opinion).

Checks

• Tested with Oracle/PostgreSQL
• Export updated
• Documentation added
• Tests added
• E2e tests created
• Successfully ran e2e tests before merge

closes GH-178

[rekt-hard]

Thank you for addressing this issue. Works fine.

Can you also address other fields? The personIdentifier and the affiliation might be set via the university already and would be overridden by an ORCID search.

Right now, we do not allow to modify already added contributors via the UI (but would be possible through the API). If we allow edits through the UI, we have to revisit this and make sure that new data takes precedence over old data.

[ValentinFutterer]

Can you also address other fields? The personIdentifier and the affiliation might be set via the university already and would be overridden by an ORCID search.

Good point, I did not think about the other fields :)

[ValentinFutterer]

The ContributorDO generated from ORCID has all fields set to null other than name, affiliation, personID and mbox. When the ContributorDOMapper is used, these null values override legit fields. What do you think of the current (naive) solution? The logic should probably be in its own mapper. Should we just add a method to ORCIDMapper like mapORCIDPersonDOToEntity? But this would just chain mapper calls. Maybe adjust mapRecordEntityToPersonDO(ORCIDRecord orcidRecord, ContributorDO contributorDO) to mapRecordEntityToPersonEntity(ORCIDRecord orcidRecord, Contributor contributor) and move the new logic in this mapper method.

[rekt-hard]

The ContributorDO generated from ORCID has all fields set to null other than name, affiliation, personID and mbox. When the ContributorDOMapper is used, these null values override legit fields. What do you think of the current (naive) solution?

Seems fine to be honest. This is a special case anyway. Adapting a general mapper would most likely lead to future issues.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
84.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud