🚸(backend) on user search match emails by Levenstein distance #575
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sampaccoud
added
bug
sampaccoud
force-pushed
the
fix-searching-user-by-email
branch
from
38b4e97 to
b077411
Compare
lunika
approved these changes
Jan 27, 2025
sampaccoud
force-pushed
the
fix-searching-user-by-email
branch
from
e640b1b to
4e07c82
Compare
When the query looks like an email (includes @) we search by Levenstein distance because we are just trying to prevent typing errors, not searching anymore. It is important to still propose results with a short Levenstein distance because it is frequent to forget a double letter in someone's name for example "Pacoud" or even "pacou" instead of "Paccoud" and we want to prevent duplicates or failing on invitation. We consider the query string to be an email as soon as it contains a "@" character. Trying harder to identify a string that is really an email would lead to weird behaviors like [email protected] looking like and email but if we continue typing [email protected] not looking like an email... before [email protected] finally looking like an email. The result would be jumping from one type of search to the other. As soon as there is a "@" in the query, we can be sure that the user is not looking for a name anymore and we can switch to matching by Levenstein distance.
sampaccoud
force-pushed
the
fix-searching-user-by-email
branch
from
4e07c82 to
9be5ae4
Compare
PanchoutNathan
force-pushed
the
fix-searching-user-by-email
branch
2 times, most recently
from
b2c161b to
0d5b791
Compare
Refactor the endActions logic to show invite user row when searching by email, removing the unnecessary length check for users
PanchoutNathan
force-pushed
the
fix-searching-user-by-email
branch
from
0d5b791 to
8fb5ed6
Compare
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
When the query looks like an email (includes @) we should search by Levenstein distance and not by trigram anymore because we are just trying to prevent typing errors, not really proposing results to a search.
It is important to still propose results with a short Levenstein distance because it is frequent to forget a double letter in someone's name for example "Pacoud" or even "Pacou" instead of "Paccoud" and we want to prevent duplicates or failing on invitation.
Proposal
fuzzystrmatchextensionWe consider the query string to be an email as soon as it contains a "@" character. Trying harder to identify a string that is really an email would lead to weird behaviors like [email protected] looking like and email but if we continue typing [email protected] not looking like an email... before [email protected] finally looking like an email. The result would be jumping from one type of search to the other. As soon as there is a "@" in the query, we can be sure that the user is not looking for a name anymore and we can switch to matching by Levenstein distance.