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

Name matching on workshop request forms #1624

Open
maneesha opened this issue Feb 26, 2020 · 7 comments
Open

Name matching on workshop request forms #1624

maneesha opened this issue Feb 26, 2020 · 7 comments
Assignees
Milestone

Comments

@maneesha
Copy link
Contributor

@maneesha maneesha commented Feb 26, 2020

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
Copy link

@Talishask Talishask commented Mar 12, 2020

@maneesha - This is great. Thanks

@pbanaszkiewicz pbanaszkiewicz self-assigned this Mar 12, 2020
@pbanaszkiewicz pbanaszkiewicz added this to the v2.12 milestone Mar 12, 2020
@pbanaszkiewicz
Copy link
Contributor

@pbanaszkiewicz pbanaszkiewicz commented Mar 12, 2020

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
Copy link

@Talishask Talishask commented Mar 12, 2020

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
Copy link
Contributor

@pbanaszkiewicz pbanaszkiewicz commented Mar 28, 2020

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.

@pbanaszkiewicz pbanaszkiewicz removed this from the v2.12 milestone May 2, 2020
@pbanaszkiewicz pbanaszkiewicz added this to the v2.13 milestone May 2, 2020
@pbanaszkiewicz pbanaszkiewicz removed this from the v2.13 milestone Jun 21, 2020
@pbanaszkiewicz pbanaszkiewicz added this to the v2.14 milestone Jun 21, 2020
@pbanaszkiewicz pbanaszkiewicz removed this from the v2.14 milestone Sep 2, 2020
@pbanaszkiewicz pbanaszkiewicz added this to the v2.15 milestone Sep 2, 2020
@sheraaronhurt
Copy link
Contributor

@sheraaronhurt sheraaronhurt commented Sep 22, 2020

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

@pbanaszkiewicz pbanaszkiewicz removed this from the v2.15 milestone Dec 6, 2020
@pbanaszkiewicz pbanaszkiewicz added this to the v2.16 milestone Dec 6, 2020
@pbanaszkiewicz pbanaszkiewicz removed this from the v2.16 milestone Jan 28, 2021
@pbanaszkiewicz pbanaszkiewicz added this to the v2.17 milestone Jan 28, 2021
@Talishask
Copy link

@Talishask Talishask commented Mar 3, 2021

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.

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

@pbanaszkiewicz pbanaszkiewicz removed this from the v3.0 milestone May 27, 2021
@pbanaszkiewicz pbanaszkiewicz added this to the v3.1 milestone May 27, 2021
@pbanaszkiewicz pbanaszkiewicz removed this from the v3.1 milestone Jun 8, 2021
@pbanaszkiewicz pbanaszkiewicz added this to the v3.2 milestone Jun 8, 2021
@pbanaszkiewicz pbanaszkiewicz removed this from the v3.2 milestone Jul 3, 2021
@pbanaszkiewicz pbanaszkiewicz added this to the v3.3 milestone Jul 3, 2021
@maneesha
Copy link
Contributor Author

@maneesha maneesha commented Aug 10, 2021

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?

@pbanaszkiewicz pbanaszkiewicz removed this from the v3.3 milestone Sep 20, 2021
@pbanaszkiewicz pbanaszkiewicz added this to the v3.4 milestone Sep 20, 2021
@pbanaszkiewicz pbanaszkiewicz removed this from the v3.4 milestone Jan 3, 2022
@pbanaszkiewicz pbanaszkiewicz added this to the v3.5 milestone Jan 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants