Skip to content

[BT-128] Migrate forwardTo Routes - 2FA Flow#89608

Merged
mjasikowski merged 23 commits into
Expensify:mainfrom
software-mansion-labs:collectioneur/dynamic-routes-remove-forward-to
May 22, 2026
Merged

[BT-128] Migrate forwardTo Routes - 2FA Flow#89608
mjasikowski merged 23 commits into
Expensify:mainfrom
software-mansion-labs:collectioneur/dynamic-routes-remove-forward-to

Conversation

@collectioneur

@collectioneur collectioneur commented May 5, 2026

Copy link
Copy Markdown
Contributor

Explanation of Change

Migrate 2FA routes (SETTINGS_2FA_ROOT, SETTINGS_2FA_VERIFY, SETTINGS_2FA_SUCCESS, SETTINGS_2FA_VERIFY_ACCOUNT) and the contact-method verify-account route from static backTo/forwardTo query params to the dynamic route system. Introduces useTwoFactorAuthRoute hook for resolving the correct 2FA entry point and useDynamicForwardPath hook for forward navigation after dynamic pages. Splits the old TwoFactorAuthPage into dedicated dynamic pages, extracts SuccessPageBase, and updates all consumers.

Fixed Issues

$ #83360

Tests

  • Verify that no errors appear in the JS console

Test 1

  1. Navigate to Settings > Security
  2. Tap Two-factor authentication
  3. If the account is not validated, verify you are redirected to the /verify-account page, and after validating you proceed to the /two-factor-auth page
  4. If the account is validated, verify the /two-factor-auth page loads, copy the recovery codes, proceed to the verify step, enter a valid code, and verify the success page appears
  5. On the success page, tap Confirm and verify you are returned to the Security settings page

Test 2

  1. Navigate to Settings > Profile > Contact methods
  2. Tap New contact method while the account is not validated
  3. Verify you are redirected to the /verify-account page (URL uses the dynamic route pattern, e.g. settings/profile/contact-methods/verify-account)
  4. After validating, verify you are forwarded to the new contact method magic code confirmation page

Test 3

  1. Navigate to Workspaces > Workspace > Accounting for a workspace that requires Xero connection
  2. Trigger the Xero connection flow that requires 2FA
  3. Verify the 2FA setup flow starts correctly and upon completion the Xero setup link opens

Test 4

  1. Have an account without 2FA.
  2. Create a mock USD bank account.
  3. Create a new workspace.
  4. Go to Workflows → Payments → Add bank account.
  5. Choose this USD account.
  6. Then click "Secure your account".
  7. Complete the 2FA setup flow.
  8. On the success page, after enabling 2FA, verify that clicking 'Got it' takes you back to the bank account modal (where you were before clicking 'Secure your account').

Offline tests

N/A

QA Steps

Same as tests

  • 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
  • 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 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 used JaimeGPT to get English > Spanish translation. I then posted it 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.ts 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 new assets were added or existing ones were modified, I verified that:
    • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
    • The assets load correctly across all supported platforms.
  • 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.
  • I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
  • 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

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

Test 1:

1_test.mov

Test 2:

2_test.mov

Test 3:

3_test.mov

Test 4:

Screen.Recording.2026-05-21.at.11.33.17.mov

@collectioneur collectioneur changed the title migrate forwardTo [BT-128] Migrate forwardTo Routes - 2FA Flow May 13, 2026
@codecov

codecov Bot commented May 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines Coverage Δ
src/ROUTES.ts 18.87% <ø> (+1.34%) ⬆️
src/SCREENS.ts 100.00% <ø> (ø)
src/hooks/useTwoFactorAuthRoute.ts 100.00% <100.00%> (ø)
src/libs/Navigation/Navigation.ts 51.55% <ø> (ø)
src/libs/Navigation/linkingConfig/OldRoutes.ts 100.00% <ø> (ø)
...igation/linkingConfig/RELATIONS/SETTINGS_TO_RHP.ts 100.00% <ø> (ø)
src/libs/Navigation/linkingConfig/config.ts 76.92% <ø> (ø)
src/libs/PaymentUtils.ts 81.03% <ø> (+0.50%) ⬆️
...nkAccount/components/BankAccountValidationForm.tsx 0.00% <ø> (ø)
...rc/pages/RequireTwoFactorAuthenticationOverlay.tsx 51.42% <100.00%> (+2.77%) ⬆️
... and 21 more
... and 151 files with indirect coverage changes

Comment thread src/ROUTES.ts
},
TWO_FACTOR_AUTH_VERIFY_ACCOUNT: {
path: 'two-factor-auth/verify-account',
entryScreens: ['*'],

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, why do you use entryScreens: ['*'] here while the top one has a list ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a RequireTwoFactorAuthenticationOverlay modal component that can appear on top of any screen in the app. It triggers when the backend signals that the user is required to have 2FA (for example, if the user is made an admin of a workspace that already has Xero set up). Since the entire 2FA flow can overlay any screen, we have to specify all screens as entryScreens here

Comment thread src/hooks/useTwoFactorAuthRoute.ts Outdated
Comment thread src/pages/settings/Security/TwoFactorAuth/DynamicVerifyPage.tsx Outdated
Comment thread src/pages/settings/Security/TwoFactorAuth/SuccessPage.tsx Outdated
Comment thread src/pages/settings/Security/TwoFactorAuth/TwoFactorAuthWrapper.tsx Outdated
Comment thread src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx Outdated
Comment thread src/pages/RequireTwoFactorAuthenticationOverlay.tsx
[SCREENS.SETTINGS.DYNAMIC_VERIFY_ACCOUNT]: undefined;
[SCREENS.SETTINGS.DYNAMIC_VERIFY_ACCOUNT]: {
// eslint-disable-next-line no-restricted-syntax -- `backTo` usages in this file are legacy. Do not add new `backTo` params to screens. See contributingGuides/NAVIGATION.md
backTo?: Routes;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to add backTo here ?

@collectioneur collectioneur May 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, verify-account was used in flows that didn't have a backTo parameter. In this batch, I added a case where the basePath for verify-account can actually have a backTo, so we are propagating backTo into verify-account. This ensures that the previous flow path isn't lost, even on a dynamic screen. Once all routes with backTo that served as a basePath for this case are migrated, this won't be needed anymore and can be removed 🙂


let forwardPath = backPath;
if (backPath === ROUTES.SETTINGS_WALLET) {
if (forwardPath === ROUTES.SETTINGS_NEW_CONTACT_METHOD_CONFIRM_MAGIC_CODE.route) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now that we have useDynamicForwardPath would be nice to move all the logic for calculating forwardPath there

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love the idea of consolidating, but it might be quite tricky to fit everything into useDynamicForwardPath. It was built more as a test for dynamic screens with forwardTo: if the screen follows the standard forward route, the function returns nothing; if it takes a non-standard route, it returns a specific path. We have some weird edge cases that would be hard to fit inside useDynamicForwardPath (like adding a backTo parameter to a route, or navigating to Xero after a goBack)

* - entryScreen: The screen that the dynamic suffix is appended to (e.g. 'Settings_Wallet').
* - forwardRoute: The destination route to navigate forward to from the dynamic route page.
*/
const FORWARD_TO_MAPPINGS: Record<string, Record<string, Route>> = {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see this in ROUTES same as entryScreens. wdyt ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since forwardTo hasn't been heavily used so far (just in about 5 routes, plus a couple we'll add after the verify-account refactoring), adding it to ROUTES.ts might be a bit much right now. It feels a bit more like a local utility rather than a global one. I could instead extract it into a separate file to keep things tidy, but I'd love to avoid cluttering ROUTES.ts 🙂

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let's maybe revisit this after couple routes w/ forward to are migrated

@jmusial jmusial left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@collectioneur collectioneur marked this pull request as ready for review May 14, 2026 13:46
@collectioneur collectioneur requested review from a team as code owners May 14, 2026 13:46
@melvin-bot melvin-bot Bot requested review from huult and joekaufmanexpensify and removed request for a team May 14, 2026 13:46
@melvin-bot

melvin-bot Bot commented May 14, 2026

Copy link
Copy Markdown

@huult 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]

@collectioneur

Copy link
Copy Markdown
Contributor Author

@huult I noticed a few bugs while checking these two flows, but don't worry, I'll have them fixed by tomorrow.
Did you come across any other issues related to this migrated flow?

@huult

huult commented May 20, 2026

Copy link
Copy Markdown
Contributor

@collectioneur I checked the other flows and they are working well.

@collectioneur

Copy link
Copy Markdown
Contributor Author

Hey @huult, I’ve fixed all the bugs. I added one more test for the USD flow. For the non-USD flow, I couldn’t get through it manually (since, as far as I know, we don’t have a mock bank account for non-USD flows). So, I just navigated directly to the finish page link and tested it that way. Everything works perfectly 👍

Screen.Recording.2026-05-20.at.12.45.11.mov

@huult

huult commented May 21, 2026

Copy link
Copy Markdown
Contributor
Screen.Recording.2026-05-21.at.15.46.26.mov

@collectioneur Before the migration, after completing the 2FA setup, the app would return to the bank account verification flow. After your migration, once 2FA setup is completed, it no longer returns to the bank account verification screen.

Could you check this? You can compare the behavior with staging to see what changed.

@huult

huult commented May 21, 2026

Copy link
Copy Markdown
Contributor
Screen.Recording.2026-05-21.at.15.58.10.mov

On the BANK_ACCOUNT_NON_USD_SETUP_FINISH page, when I go back, it redirects to the Security page, which is incorrect.

In staging, it correctly goes back to the BANK_ACCOUNT_NON_USD_SETUP_FINISH flow instead. Could you check this issue?

@collectioneur

Copy link
Copy Markdown
Contributor Author

On the BANK_ACCOUNT_NON_USD_SETUP_FINISH page, when I go back, it redirects to the Security page, which is incorrect.

In staging, it correctly goes back to the BANK_ACCOUNT_NON_USD_SETUP_FINISH flow instead. Could you check this issue?

It happens due to #89710, where fullscreen screens aren't updating when navigating to certain modals. As soon as that issue is resolved, this bug will also be fixed because we'll route to a static enabled page and the fullscreen will instantly update to settings/security. Previously on staging, the enabled page was part of the 2fa root page and had a backTo param. Now, after the refactoring, it is static and will route directly to settings/security

@collectioneur

Copy link
Copy Markdown
Contributor Author

@collectioneur Before the migration, after completing the 2FA setup, the app would return to the bank account verification flow. After your migration, once 2FA setup is completed, it no longer returns to the bank account verification screen.

Could you check this? You can compare the behavior with staging to see what changed.

Screen.Recording.2026-05-21.at.11.33.17.mov

Resolved, thanks!

@huult

huult commented May 21, 2026

Copy link
Copy Markdown
Contributor

Too quick, haha. I’ll re-check this PR in the next 4 hours

@huult huult left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@melvin-bot melvin-bot Bot requested a review from mjasikowski May 22, 2026 02:58
@mjasikowski mjasikowski merged commit 49c5907 into Expensify:main May 22, 2026
41 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

🚧 @mjasikowski has triggered a test Expensify/App build. You can view the workflow run here.

@OSBotify

Copy link
Copy Markdown
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify

Copy link
Copy Markdown
Contributor

🚀 Deployed to staging by https://github.com/mjasikowski in version: 9.3.80-0 🚀

platform result
🕸 web 🕸 success ✅
🤖 android 🤖 success ✅
🍎 iOS 🍎 success ✅

Bundle Size Analysis (Sentry):

@MelvinBot

Copy link
Copy Markdown
Contributor

No help site changes are required for this PR.

This PR is a purely internal code refactoring — it migrates 2FA routes from static backTo/forwardTo query params to a dynamic route system, introduces new hooks (useTwoFactorAuthRoute, useDynamicForwardPath), and splits internal page components. None of these changes affect user-facing behavior, UI labels, navigation steps, or feature names.

The existing help article at docs/articles/new-expensify/settings/Two-Factor-Authentication.md remains accurate — the user-visible flow for enabling and using 2FA is unchanged.

@OSBotify

Copy link
Copy Markdown
Contributor

🚀 Deployed to production by https://github.com/luacmartins in version: 9.3.81-2 🚀

platform result
🕸 web 🕸 success ✅
🤖 android 🤖 success ✅
🍎 iOS 🍎 success ✅

return setError(translate('twoFactorAuth.errorStepCodes'));
}
Navigation.navigate(ROUTES.SETTINGS_2FA_VERIFY.getRoute(route.params?.backTo, route.params?.forwardTo));
Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.TWO_FACTOR_AUTH_VERIFY.path, backPath), {forceReplace: true});

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we using forceReplace here @collectioneur @huult ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@parasharrajat What issue does this cause? We need forceReplace to fix an issue where users can't navigate back

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have steps for that issue or any comments? We are solving this #92544

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants