[$250] User validation –User logging out when validate account in NewDot that was created in OldDot

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.68-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4524500
Email or phone of affected tester (no customers): ponikarchuks+830424@gmail.com
Issue reported by: Applause - Internal Team

Action Performed:

1. Log out of both NewDot and OldDot
2. Navigate to OldDot https://staging.expensify.com/
3. In the login screen enter a new gmail account
4. Verify you're navigated to staging NewDot
5. Navigate to account Settings > 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

Expected Result:

The account is validated

Actual Result:

User logging out when try to validate account in NewDot that was created in OldDot. On step 6 User receive a magic code only after resend it

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6466569_1714482054776.validate_account_in_NewDot.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0126755b0189ef4aa2
• Upwork Job ID: 1785612522728562689
• Last Price Increase: 2024-05-29
• Automatic offers:
• c3024 | Reviewer | 102590991

[melvin-bot]

Triggered auto assignment to @sonialiap (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[lanitochka17]

@sonialiap FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[humanitiesclinic]

I tried this, and did not receive any verification code at all with humanitiesclinic+exp@gmail.com, despite clicking on resend multiple times.

[melvin-bot]

📣 @humanitiesclinic! 📣
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>

[humanitiesclinic]

Contributor details
Your Expensify account email: humanitiesclinic@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01dd0a657e935bad4f?viewMode=1

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0126755b0189ef4aa2

[melvin-bot]

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

[melvin-bot]

@sonialiap, @c3024 Huh... This is 4 days overdue. Who can take care of this?

[sonialiap]

Looking for proposals

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@sonialiap, @c3024 Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@sonialiap @c3024 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[sonialiap]

looking for proposals, will retest later this week

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[c3024]

Waiting for proposals.

[c3024]

@teneeto

This was unfortunately reverted here #46846 . Reason here #46723.

I think this seems be one of the cases of "You might not need an Effect" we missed. 😃

Instead of using useEffect I think we can attach the API request to onPress here

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

Line 83 in 53eee53

onPress={() => Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHOD_DETAILS.getRoute(partnerUserID))}

something like this

                    onPress={() => {Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHOD_DETAILS.getRoute(partnerUserID));
                        if (!login?.validatedDate) {
                            User.requestContactMethodValidateCode(loginName);
                        }
                    }}
                   

or have an empty dependency array for the useEffect.

[melvin-bot]

@sonialiap, @teneeto, @narefyev91, @c3024 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[teneeto]

@teneeto

This was unfortunately reverted here #46846 . Reason here #46723.

I think this seems be one of the cases of "You might not need an Effect" we missed. 😃

Instead of using useEffect I think we can attach the API request to onPress here

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

Line 83 in 53eee53

onPress={() => Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHOD_DETAILS.getRoute(partnerUserID))}

something like this

                    onPress={() => {Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHOD_DETAILS.getRoute(partnerUserID));
                        if (!login?.validatedDate) {
                            User.requestContactMethodValidateCode(loginName);
                        }
                    }}
                   

or have an empty dependency array for the useEffect.

Ok I can take a look again.

[melvin-bot]

Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[sonialiap]

@johncschuster I'm OOO Aug 19-30, adding leave buddy.
Status: waiting for code correction

[c3024]

Tagging all involved: @marcaaron, @trjExpensify, @jasperhuangg, and @thienlnam in issue #46723 and the revert #46846 of the earlier PR #45395 for this issue.

Can you please clarify this?

When we add a contact method, the backend sends an email with a validation code even before the user visits the validation code form.

If the user doesn't verify immediately, and later clicks on this secondary contact method, they are directed to the validation code form. However, no new magic code is sent immediately; it is only sent after the user clicks on the "Didn't receive a magic code" link, as described in the Actual Result of this issue.

On step 6, the user receives a magic code only after resending it.

What should be the expected behaviour here?

1. Send a code right after adding the contact method, regardless of whether the user visits the validation code page. After that, do not send any code when simply visiting a contact method page. A new code should only be sent when the "Didn't receive a magic code" link is clicked on the Contact Method page. This is the existing behaviour.
2. Do not send a code right after adding the contact method. Instead, send the code only when the validation code method page for a contact method is visited. With this approach, a code is sent right after the user visits the validation code form for a secondary contact method. Further code requests can be made by clicking on the "Resend validation code" link on the page.

I think option (2) is better because adding a secondary contact method only takes the user to the Contact Methods page. The user needs to click on a contact method to go to the validation form. Therefore, on this event handler, we can request the code with requestContactMethodValidateCode.

Thanks!

[trjExpensify]

For clarity and not conflating two different cases, let's lay them out:

Case 1: Signed-up, hasn't validated the primary login yet.

1. Signs-up
2. Gets signed-in because we allow that unvalidated session
3. Heads to Profile > Contact method
4. Clicks on the primary contact that's unvalidated
5. A magic code link should be sent

Case 2: Adds a secondary login to an existing account

1. Heads to Profile > Contact method
2. Clicks "Add contact method"
3. Adds a secondary login
4. An email to notify the primary login that a secondary contact method was added to their account is sent right away for visibility/security, and includes a magic code/link to verify it (below for ref).

So in case 2 when adding a secondary login, the bug here was that we were sending two magic code emails in addition, as a result of the change that was reverted:

[c3024]

Thanks, @trjExpensify.

So, I think this should be the expected behaviour. Can you please check if this is correct?

Case 1:

1. When we click on the unvalidated primary contact method, a security code should be sent each time.

Case 2:

1. When we click on a secondary contact method, a security code should not be sent on this click alone, as it was already sent when the secondary contact method was added.

[trjExpensify]

Case 1, yup!

Case 2, not quite. I think we should:

1. Click New contact method
2. Enter a new login
3. Click Add
4. Fire off the secondary login email only and navigate to the magic code input page to validate it

That way, we 1) aren't sending additional magic code emails and 2) we aren't asking the user to click the unvalidated secondary login to validate it right after adding it which would cause us to fire another one off like case 1.

Does that make sense? CC: @Expensify/design

[sonialiap]

@johncschuster back from OOO, releasing you from buddy role :D

[sonialiap]

@c3024 we have clarification from Tom for the expected behavior. Is the next step to implement and push a PR?

[teneeto]

@sonialiap, O yes, I already did a push for that change, but I am working a way around this comment: #47772 (comment)

We should push a final fix today.

[c3024]

There have been some changes in these flows since our last discussion.

Now, if we want to add a secondary contact, we need to re-validate our primary login before adding the secondary contact. As it stands, this validation page is identical to the usual first-time code verification page.

The flow for case 2 will be now as follows:

1. Click New Contact Method.
2. Enter a new login.
3. Click Add.
4. The verification page for the primary login appears, as this is the current flow.
5. Once the primary login is validated, we proceed to the code validation page for the secondary login.
6. Currently, both pages (4 and 5) look the same, with the only difference being the email address. This could be confusing for users. It might be clearer to add specific information to the primary contact verification page in Step 4, such as "Verify your primary contact first to add a secondary contact."

Should we also update the text on the primary contact validation page?

[trjExpensify]

Ah, nice catch on changes in this flow to verify access to the primary login. I guess that might changes things a bit.

The flow for #41330 (comment) will be now as follows:

1. Click New Contact Method.
2. Enter a new login.
3. Click Add.
4. The verification page for the primary login appears, as this is the current [HOLD for payment 2024-09-18] Update the Magic code form to be easier to reuse in other flows and add it to Reveal card details flow #48541 (comment).
5. Once the primary login is validated, we proceed to the code validation page for the secondary login.
6. Currently, both pages (4 and 5) look the same, with the only difference being the email address. This could be confusing for users. It might be clearer to add specific information to the primary contact verification page in Step 4, such as "Verify your primary contact first to add a secondary contact."

Should we also update the text on the primary contact validation page?

For the benefit of the discussion and design input, can you add a video of this flow so we can see the problem it presents please? Thanks!

[teneeto]

@c3024 @trjExpensify how do we plan to proceed with this? I'm waiting for your lead 😌.

[trjExpensify]

Hoping @c3024 can provide us a video of the current behaviour, so we can discuss those next steps.

For the benefit of the discussion and design input, can you add a video of this flow so we can see the problem it presents please? Thanks!

[c3024]

Now, with the changes in the PR #47772, the secondary contact verification page appears only for a brief period and redirects to ContactMethodsPage.

secondaryContactChrome.mp4

I think this needs to be fixed first. @teneeto

[teneeto]

on it.

[teneeto]

I'm sorry for not getting back to you sooner. This should be the current state for the secondary contact method.

Screen.Recording.2024-09-13.at.10.22.54.mov

[c3024]

The earlier PR was reverted because of this flow after addition of secondary contact

1. Backend sends a validate code immediately for the secondary contact
2. But since we redirect to the ContactMethodsPage, we still have to click again on the secondary contact method and another code is requested from front-end.

This flow still remains with this PR. Here is the video.

magicCodeSentWhenAddingSecondaryContact.mp4

We need to redirect the user not to ContactMethodsPage but to the validate code page to use the code immediately received in Step 1.

[teneeto]

More straightforward to follow now, 100% get you. I will add a fix and push back. Thanks @c3024

[teneeto]

@c3024 can you confirm this is the expected flow?

Screen.Recording.2024-09-17.at.10.38.58.mov