Fix send code validation

[teneeto]

Details

This PR fixes issue with sending email validation link. When a user triggers email validation from profile, the magic sign-in code isn't sent immediately till you have to trigger Didn't receive a magic code?. This PR is raise to fix a reverted code merge #46846

Fixed Issues

$: 41330
PROPOSAL: issuecomment

Tests

Verifying newly added account

1. Make sure you are Logged out of both NewDot and OldDot
2. Navigate to OldDot https://staging.expensify.com/
3. In the login screen enter a new gmail account (make sure it's a gmail account as my work email didn't work)
4. Verify you're navigated to staging NewDot
5. Navigate to account Settings > profile > Contact methods
6. Click on the email
7. Verify you're prompted for the magic code to validate the account
8. Verify the account receives a magic code to their email inbox
9. Enter the magic code in the field
10. Click on Verify

Adding a Secondary Contact

1. add a new contact method
2. clicking on "add" button should take you to validate code form
3. Clicking on a contact in the contact methods should trigger a validate code request

Expectation: The validation link is sent first time, and user is not logged out when magic code is entered.

• Verify that no errors appear in the JS console

Offline tests

Verifying newly added account

1. Make sure you are Logged out of both NewDot and OldDot
2. Navigate to OldDot https://staging.expensify.com/
3. In the login screen enter a new gmail account (make sure it's a gmail account as my work email didn't work)
4. Verify you're navigated to staging NewDot
5. Navigate to account Settings > profile > Contact methods
6. Click on the email
7. Verify you're prompted for the magic code to validate the account
8. Verify the account receives a magic code to their email inbox
9. Enter the magic code in the field
10. Click on Verify

Adding a Secondary Contact

1. add a new contact method
2. clicking on "add" button should take you to validate code form
3. Clicking on a contact in the contact methods should trigger a validate code request

Expectation: The validation link is sent first time, and user is not logged out when magic code is entered.

QA Steps

Verifying newly added account

1. Make sure you are Logged out of both NewDot and OldDot
2. Navigate to OldDot https://staging.expensify.com/
3. In the login screen enter a new gmail account (make sure it's a gmail account as my work email didn't work)
4. Verify you're navigated to staging NewDot
5. Navigate to account Settings > profile > Contact methods
6. Click on the email
7. Verify you're prompted for the magic code to validate the account
8. Verify the account receives a magic code to their email inbox
9. Enter the magic code in the field
10. Click on Verify

Adding a Secondary Contact

1. add a new contact method
2. clicking on "add" button should take you to validate code form
3. Clicking on a contact in the contact methods should trigger a validate code request

Expectation: The validation link is sent first time, and user is not logged out when magic code is entered.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

MacOS: Chrome / Safari

Screen.Recording.2024-08-21.at.08.35.06.mov

iOS: Native

Android: Native

Android: mWeb Chrome

iOS: mWeb Safari

MacOS: Desktop

[melvin-bot]

@nkuoch Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[teneeto]

Hi @c3024, can we check for the update here.

[c3024]

Automation did not work. Commenting so that it appears on my K2.

[c3024]

Based on the clarification for case (2) here,

we need changes here,

App/src/libs/actions/User.ts

Line 347 in fc849dd

Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));

-     Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));
+     Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHOD_DETAILS.getRoute(contactMethod));

and here,

App/src/pages/settings/Profile/Contacts/ContactMethodDetailsPage.tsx

Line 152 in fc849dd

Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));

-         Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));
+    Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo));

[teneeto]

Hi @c3024, let's check this again.

[c3024]

The first change mentioned here for User.ts is required for sending code correctly for secondary contacts. This is not included in the PR. Otherwise the API request is made for sending code for the primary contact.

Here is the video showing this bug.

validateChromeBug.mp4

[teneeto]

Hi @c3024, I haven't added that piece yet, seeing that there was a recent code change which removed navigation completely: https://github.com/Expensify/App/pull/48320/files#r1738644645

I'm still trying to figure out why that was done and what next to do. As it stands, adding that piece gives this flickering navigation behaviour as shown in the screen record

Screen.Recording.2024-09-04.at.14.26.25.mov

[teneeto]

@c3024 added a fix and resolved your comment.

[teneeto]

Ping! ping!! @c3024

[teneeto]

@c3024 can we check this one again

[c3024]

Sorry, I missed the tag. Checking today.

[c3024]

In the new contact adding flow, when we validate the primary contact, the secondary contact should be added to the contact methods.

Previously, when validating the primary contact using the magic code in the new contact method flow, the app navigated to the ContactMethodsPage.

Now, it navigates to the ContactMethodDetails page, allowing the user to go back without validating the secondary contact. If the user goes back again to the primary contact validation code page, the newly added but not yet validated secondary contact is removed locally

App/src/pages/settings/Profile/Contacts/NewContactMethodPage.tsx

Line 168 in c18812a

User.clearContactMethod(pendingContactAction?.contactMethod);

and does not appear in the ContactMethodsPage.

On this branch compared to staging:

contactNotInContactMethodsPage.mp4

The secondary contact method is still written to the backend, so it reappears after logging out and logging back in:

logOutAndLogin.mp4

[waterim]

@c3024 Should work fine now

[waterim]

@c3024 bump

[waterim]

@c3024 bump

[c3024]

Thanks for the bump. I will check and update!

[c3024]

Magic code is sent twice when adding a secondary contact.

Like mentioned here in Step 7 in Test 2, there should be no duplicate magic code emails when adding a secondary contact.

Screen.Recording.2024-12-05.at.1.10.50.PM.mov

[waterim]

Ahh, okay, didn't see those steps

[waterim]

update: found a root, trying to fix it without breaking other parts

[waterim]

@c3024 Im getting super weird issues after merging main

[waterim]

And also on staging Im getting the same issue with double emails

[c3024]

@waterim

On staging:
1. Add a contact method.
2. Validate the primary contact.
3. Navigates to the Contact Method Page.

Between steps 2 and 3, a magic code was sent by the backend. Then, on clicking the contact method, another magic code was sent due to the frontend request.

On this branch:
1. Add a contact method.
2. Validate the primary contact.
3. Navigates to the validation modal for the secondary contact.

Between steps 2 and 3, a magic code was sent by the backend. When the secondary contact method validation modal opens, another magic code was sent due to the frontend request.

History of this issue:
1. There was an issue where clicking on a contact method did not send a magic code immediately.
2. That was fixed with PR #45395.
3. This was reverted because of this.
4. This solution addresses the prevention of duplicate codes.
5. The present PR tried to tackle both issues.
6. Meanwhile, the issue of not sending a magic code on clicking a contact method seems to have been fixed by another PR.
7. The remaining issue is to fix the duplicate code issue without breaking any other functionality. Based on the previous reviews, I found these conditions that usually broke due to changes in this PR and suggested relevant tests.

[waterim]

@c3024 Didnt you get the same not found on this branch after I merged main?

[waterim]

Thank you for the detailed history, it helps a lot!

[c3024]

Yes, I am also seeing the same Not Found after validating the primary contact when adding a secondary contact.

[waterim]

Okay, finally I found that this change caused this not-found, as now contactMethod is setting to null and validation now works in a different way because of that

To be honest Im a bit confused with all these changes, this flow is changing all the time and each merge breaking some part of the logic

Initial issue for this PR was also closed yesterday, do we still want this PR to proceed?
As far as I understand this PR was about to fix the code validation, but right now it looks like we changed the flow fully, but during this PR is ongoing there are a lot of changes from outside coming to this flow and it looks like everything works perfectly without this changes from here.

Can you please describe the desired/expected solution from this PR?

I mean I cant find any expected behaviour, main issue was already closed yesterday, the flow works perfectly now without these changes and Im not sure what to do next, trying to change all fixes from other PRs or adjust to new changes or close this ticket as initial issue doesnt exist anymore

[c3024]

Yes, I think we can close this PR. If necessary, a new issue can be created to fix the duplicate codes issue.