Name matching on workshop request forms

[maneesha]

When we get a workshop request form, we have the option to add the the person who requested it to the database if they are not already in.

@pbanaszkiewicz Can you clarify the conditions for having a person considered to be a matching person? We've come across cases where the name may not be an exact match but the email is an exact match (i.e., "John Smith" vs "John J. Smith" both have the email address jsmith@example.com) -- and it does not recognize a matching person. We then have the option "This person is not in the database. Click to add them."

Could we have AMY suggest a possible matching person, and then let us select a matching person if that was not a correct match? I'm thinking something like what we do when we match an instructor training application to an existing person.

Note: this issue replaces an issue raised by @Talishask that included actual names/emails of people. I deleted that to avoid publicly sharing personal inforamation. Talisha, please feel free to respond here as to whether I've captured your original intent. Piotr- if you want to see some real examples of what we're talking about I can share those by email.

[Talishask]

@maneesha - This is great. Thanks

[pbanaszkiewicz]

Hi @Talishask and @maneesha - the matching criteria are defined in CommonRequest.host() as below:

person.personal = request.personal AND
person.family = request.family AND
person.email = request.email

A single match is returned, or nothing.

The problem, I think, is that we don't link any of the 3 workshop requests (workshop request, workshop inquiry, self-organised submission) to the person in AMY who submitted them. So this message "This person is not in the database. Click to add them." is purely informational. I could change this information to show all possible matches in current DB.

[Talishask]

We definitely need an update of some type, but what exactly the criteria should be is what I'm trying to think about. @maneesha feel free to chime in here on my thoughts:

I think the most reliable indicator will be email, although there are rare occasions when someone submits from a secondary email in which case we would need to consider both email addresses (primary or secondary). I'm not sure if we want to say email needs to match for sure and the other variables are optional, just so that we can see some possibilities?

We don't want to depend on too many matching criteria because then we limit our matching abilities, but we also don't want it to be too wide because then there will always be a list of possibilities.

Could we do something that is a case by case basis, like:

• If email (primary or secondary) and personal and family match = Matched Person
• If email (primary or secondary) and family match = Matched Person [note: since first names are usually where nick names come in]
  Then if neither of the above for sure matching person cases exists suggest possible matches based on personal and family match?

[pbanaszkiewicz]

Hi @Talishask

Could we do something that is a case by case basis, like:

* If email (primary or secondary) and personal and family match = Matched Person

* If email (primary or secondary) and family match  = Matched Person _[note: since first names are usually where nick names come in]_
  Then if neither of the above for sure matching person cases exists suggest possible matches based on personal and family match?

This is definitely possible to implement.

[sheraaronhurt]

I love this! Thanks for providing the options @Talishask . This will be great!

[Talishask]

Hey, I have located another thing related to this issue, so I hope it is okay to add it here. Let me know if a new issue should be created.

Currently, Case sensitive matching of the Host institution and possibly also names is blocking matching. Here is one workshop submission that did not match a host institution because the name in AMY used all lowercase and the person used mixed cases in their submission. Although these should have matched at least based on the URL of the organisation.

• https://amy.carpentries.org/requests/selforganised_submission/815/

I think I noticed the similar thing for names. Is this something we can update?

[maneesha]

Tagging @lauryndbrown and @fmichonneau in this also, as this relates to creating new Person profiles and the consents required for doing so. Is there anything we should consider from that perspective?