[HOLD for payment 2024-01-22] [HOLD for payment 2023-12-28] [$1000] Search - The search function is not working correctly with US phone number

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Click on the Search icon in the header.
2. Enter any US phone number, for example, "+15005550009"
3. Confirm that the number appears in the result list because it is a valid number.
4. Add "1" to the beginning of that number (after +)
5. Observe that the search result still displays the number from step Add Expensify eslint #3, even though it NO LONGE matches the NEW number in step Moving files and folders a little #4.

Expected Result:

The search result will only be displayed if it exactly matches the search number.

Actual Result:

The search result continues to be displayed even though it doesn't match the search number.

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.75.2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

iOS-Native.MP4

MacOS-Chrome.mp4

iOS-Safari.MP4

MacOS-Desktop.mov

MacOS-Safari.mov

Android-Native.mp4

Android-Chrome.mp4

Recording.4795.mp4

Expensify/Expensify Issue URL:
Issue reported by: @tranvantoan-qn
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695839159212839

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011d925aad5414539c
• Upwork Job ID: 1707761651715391488
• Last Price Increase: 2023-10-30
• Automatic offers:
• aimane-chnaif | Reviewer | 27770911
• barros001 | Contributor | 27770914
• tranvantoan-qn | Reporter | 27770919

[melvin-bot]

Triggered auto assignment to @sophiepintoraetz (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~011d925aad5414539c

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[abzokhattab]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Some phone numbers options are not matching the input in the search

What is the root cause of that problem?

we use the awesome-phonenumber to verify the validity of the input numbers which is built on top of this library
libphonenumber

so according to this issue i opened on libphonenumber issues forum, the entered number is a valid one however the e164result ignores the additional national number '1' after the country code '+1' for US numbers before parsing it. For "+115005550009" it will parse it as "+15005550009"

therefore a wrong number is displayed

What changes do you think we should make in order to solve the problem?

instead of showing the e164 format we can show the input value after sanitizing it in case the number is valid :

App/src/libs/OptionsListUtils.js

Lines 1017 to 1018 in e8ea488

	const parsedPhoneNumber = parsePhoneNumber(LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue)));
	const searchValue = parsedPhoneNumber.possible ? parsedPhoneNumber.number.e164 : searchInputValue.toLowerCase();

we can change it to:

  const inputPhone= LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue));
  const parsedPhoneNumber = parsePhoneNumber(inputPhone);
    const searchValue = parsedPhoneNumber.possible ? inputPhone : searchInputValue.toLowerCase();

POC:

[cooldev900]

Proposal

from: @cooldev900

Please re-state the problem that we are trying to solve in this issue.

The search function is not working correctly with US phone number when adding "1" to the beginning of that number (after +)

What is the root cause of that problem?

App/src/libs/OptionsListUtils.js

Line 999 in dfb3f9b

const parsedPhoneNumber = parsePhoneNumber(LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue)));

The value of parsedPhoneNumber.number.e164 is the same result whether it has extra "1"/space or not in country code part of US phone number.

What changes do you think we should make in order to solve the problem?

We can add extra US phone number validation.
We have to check if number.e164 of parsed phone number is same as it's input when the search value is possible to be phone number

const searchValue = parsedPhoneNumber.possible && parsedPhoneNumber.number.e164 === LoginUtils.getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number.input) ?  parsedPhoneNumber.number.e164 : searchInputValue.toLowerCase();

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

📣 @cooldev900! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[cooldev900]

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/~01ddb2d86c2fc76364

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[FitseTLT]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Search results appear for invalid US phone numbers like "+115005550009" (which are phone numbers with an extra '1' adjacent to the country code '+1' on a correct US phone number).

What is the root cause of that problem?

The awesome-phonenumber library's parsePhoneNumber function ignores the additional '1' after the country code '+1' for US phone numbers before parsing it. For "+115005550009" it will parse it as if "+15005550009" is inserted as its parameter.

What changes do you think we should make in order to solve the problem?

We need to have an additional logic for these exceptional cases.
So we need to change this

App/src/libs/OptionsListUtils.js

Line 981 in 71db96d

const searchValue = parsedPhoneNumber.possible ? parsedPhoneNumber.number.e164 : searchInputValue.toLowerCase();

to
const isValid = parsedPhoneNumber.possible && LoginUtils.getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number.input) === parsedPhoneNumber.number.e164; const searchValue = isValid ? parsedPhoneNumber.number.e164 : searchInputValue.toLowerCase();
And change this

App/src/libs/OptionsListUtils.js

Line 1162 in 71db96d

(parsedPhoneNumber.possible && Str.isValidPhone(LoginUtils.getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number.input)))) &&

to
`
(isValid && Str.isValidPhone(LoginUtils.getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number.input)))) &&

And change this https://github.com/Expensify/App/blob/71db96d8a77068220fac73ca0dc984796ff862f9/src/libs/OptionsListUtils.js#L1466 to
const isValidPhone =
parsePhoneNumber(LoginUtils.appendCountryCode(searchValue)).possible &&
LoginUtils.getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number.input) === parsedPhoneNumber.number.e164;

`

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

📣 @FitseTLT! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[FitseTLT]

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/~01aabb4fb3019558fb

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[sophiepintoraetz]

Waiting on @aimane-chnaif here!

[sophiepintoraetz]

Bump for @aimane-chnaif!

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[barros001]

@aimane-chnaif finalized my PR, its ready for review.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.14-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: treat certain US numbers as invalid #31726

If no regressions arise, payment will be issued on 2023-12-28. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @barros001 requires payment automatic offer (Contributor)
• @aimane-chnaif requires payment automatic offer (Reviewer)
• @tranvantoan-qn requires payment automatic offer (Reporter)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@aimane-chnaif] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@aimane-chnaif] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@aimane-chnaif] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@sophiepintoraetz] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[sophiepintoraetz]

hi @barros001 @aimane-chnaif - just a quick note that the payment due date is in the middle of my OOO - I am likely not online to process this but will be back on 3 Jan and will process it then! In the meantime, please make sure you have accepted the offers and @aimane-chnaif, you have completed the BZ checklist before then.

[melvin-bot]

@barros001, @madmax330, @sophiepintoraetz, @aimane-chnaif Whoops! This issue is 2 days overdue. Let's get this updated quick!

[aimane-chnaif]

Latest update: waiting for test result from users with tons of phone contacts

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.24-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: treat certain US numbers as invalid #33605

If no regressions arise, payment will be issued on 2024-01-22. 🎊

For reference, here are some details about the assignees on this issue:

• @barros001 requires payment automatic offer (Contributor) - ✅
• @aimane-chnaif requires payment automatic offer (Reviewer)
• @tranvantoan-qn requires payment automatic offer (Reporter) ✅

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@aimane-chnaif] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@aimane-chnaif] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@aimane-chnaif] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@sophiepintoraetz] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[sophiepintoraetz]

@aimane-chnaif - I will release payment once the checklist has been completed. Closing for now, feel free to ping me once you've done it.

[aimane-chnaif]

• The PR that introduced the bug has been identified. Link to the PR: N/A
• The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
• A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• Determine if we should create a regression test for this bug. We added automated test for this specific case so that should cover regression test
• If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.