Author claiming checks for whether to create a ticket are wrong

[michamos]

inspirehep/inspirehep#2403 outlines the approach to claiming papers from a different profile. There is an important distinction of whether users are allowed to claim the papers, or a ticket for a curator should be created instead.

The checks that are implemented are not in line with the requirements however:

• In https://github.com/inspirehep/inspirehep/blob/492a3643f2d346ab2ef27b0ea33dc78b98c9df4d/backend/inspirehep/assign/views.py#L169, the code checks whether the paper is curated instead of whether the current signature is already claimed (curated_relation field of corresponding author in paper).
• In https://github.com/inspirehep/inspirehep/blob/492a3643f2d346ab2ef27b0ea33dc78b98c9df4d/backend/inspirehep/assign/utils.py#L102-L134, the name compatibility check is completely wrong. The check should be whether there is a last name in common between the signature that the user wants to claim and the names (including variants) in the user profile. The fields in the author profile to look at are name.value and name.name_variants. ASCII-fication of unicode characters should be performed.

Examples:

Author name in paper (authors.full_name)	Author name in profile (name.value OR name.name_variants)	can_claim
Smith, John	Smith, J.	✅
Smith, J.	Smith, John	✅
Smith Davis, J.	Smith, Robert	✅
Davis, J.	Smith Davis, P.	✅
Smith, J.	Davis, Smith	❎
Smïth, J.	Smith, J.	✅
Smith Davis	Smith, J.	✅
Smith, J.	Smith	✅

[drjova]

@michamos it's not clear for me, for example if I have {Smith, Davis} and {Smith} should we allow claim or not?

[michamos]

Yes, that's like the last row in the table Le jeu. 13 juin 2024, 10:19, Harris Tzovanakis ***@***.***> a écrit :

…

@michamos <https://github.com/michamos> it's not clear for me, for example if I have {Smith, Davis} and {Smith} should we allow claim or not? — Reply to this email directly, view it on GitHub <#467 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWC7MPGZDHTIM6DC6V23ZDZHFIYJAVCNFSM6AAAAABHZZCM66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRUHE3DCNJQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[drjova]

The issue is the ParsedName when we have just Smith it parsed like a first name, is it a bug or should we make a special case for that?

name = "Smith"
ParsedName.loads(name)

<HumanName : [
        title: '' 
        first: 'Smith' 
        middle: '' 
        last: '' 
        suffix: ''
        nickname: ''
]>

[michamos]

It's a bit of a corner case, but I think in general last name makes more sense. I believe we already have some workarounds for this somewhere, as the query parser handles it as a last name: https://inspirehep.net/api/search/query-parser?q=a+smith Le jeu. 13 juin 2024, 10:35, Harris Tzovanakis ***@***.***> a écrit :

…

The issue is the ParsedName when we have just Smith it parsed like a first name, is it a bug or should we make a special case for that? name = "Smith"ParsedName.loads(name) <HumanName : [ title: '' first: 'Smith' middle: '' last: '' suffix: '' nickname: '' ]> — Reply to this email directly, view it on GitHub <#467 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWC7MPLULZTD4N5AM4SG6DZHFKTXAVCNFSM6AAAAABHZZCM66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRUHE4TSNZRHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[drjova]

Yeah right, I forgot the Pink case 😅

We have also this Smith Davis & Smith, J.

Our parser returns:

<HumanName : [
        title: '' 
        first: 'J.' 
        middle: '' 
        last: 'Smith' 
        suffix: ''
        nickname: ''
]>

and

<HumanName : [
        title: '' 
        first: 'Smith' 
        middle: '' 
        last: 'Davis' 
        suffix: ''
        nickname: ''
]>

Which are incompatible, should we handle this case as well? Or it's a mistake in the requirements?