83867 travel workspace by huult · Pull Request #98631 · Expensify/App

huult · 2026-08-14T06:15:34Z

Explanation of Change

Fixed Issues

$ #83867
PROPOSAL:

Tests

Same QA step

Verify that no errors appear in the JS console

Offline tests

QA Steps

TRAVEL_VERIFY_ACCOUNT

Precondition:

Travel feature is enabled.
Log in with a private domain account that has not been verified.

Open the Expensify app.
Go to Workspace → Travel.
Click the Let's Go button
Verify that the Verify Account step opens and that you can navigate forward and back normally.

TRAVEL_WORKSPACE_CONFIRMATION

Precondition:

Account doesn't have any workspace.
Log in with a private domain account.

Open the Expensify app.
Go to Spend.

Update the URL from:
https://staging.new.expensify.com/search?q=type%3Aexpense-report%20sortBy%3Adate%20sortOrder%3Adesc

to:
https://staging.new.expensify.com/search/travel-upgrade?q=type%3Aexpense-report%20sortBy%3Adate%20sortOrder%3Adesc

Click the Upgrade button.
Verify that the Workspace Confirmation screen appears and that you can proceed through the flow normally.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

TRAVEL_VERIFY_ACCOUNT

Screen.Recording.2026-08-14.at.13.06.19.mov

TRAVEL_WORKSPACE_CONFIRMATION

Screen.Recording.2026-08-14.at.13.14.48.mov

melvin-bot · 2026-08-14T06:15:40Z

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

codecov · 2026-08-14T06:19:47Z

Codecov Report

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

Files with missing lines	Coverage Δ
src/ROUTES.ts	`23.38% <100.00%> (+0.02%)`	⬆️
src/SCREENS.ts	`100.00% <ø> (ø)`
src/components/BookTravelButton.tsx	`81.57% <ø> (ø)`
src/libs/Navigation/linkingConfig/OldRoutes.ts	`100.00% <ø> (ø)`
src/libs/Navigation/linkingConfig/config.ts	`66.66% <ø> (ø)`
src/pages/Travel/DynamicTravelUpgrade.tsx	`0.00% <ø> (ø)`
src/pages/Travel/EnableTravel/index.tsx	`0.00% <ø> (ø)`
...avel/DynamicWorkspaceConfirmationForTravelPage.tsx	`0.00% <0.00%> (ø)`
...gation/AppNavigator/ModalStackNavigators/index.tsx	`6.38% <0.00%> (ø)`
src/pages/Travel/DynamicVerifyAccountPage.tsx	`0.00% <0.00%> (ø)`
... and 12 files with indirect coverage changes

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3b59ff97bd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-08-14T06:26:14Z

        }
        setTravelProvisioningNextStep(ROUTES.TRAVEL_ENABLE.getRoute(policyID));
-        Navigation.navigate(ROUTES.TRAVEL_VERIFY_ACCOUNT.getRoute(undefined, policyID), {forceReplace: true});
+        Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.TRAVEL_VERIFY_ACCOUNT.getRoute(policyID)), {forceReplace: true});


Avoid returning to the guarded enable route

When this redirect runs from EnableTravel for an unvalidated user, createDynamicRoute() uses the current /travel/enable/:policyID URL as the dynamic route base. DynamicVerifyAccountPage then derives navigateBackTo from that base, so dismissing the validation page navigates back to EnableTravel, whose effect immediately redirects to verify-account again. The previous static verify route with forceReplace did not set the enable stepper as the close target, so users can now get stuck in the verify screen unless they complete validation.

Useful? React with 👍 / 👎.

I can't reproduce this case. @suneox, can you reproduce it?

huult · 2026-08-14T08:09:04Z

@suneox it's ready for review

garrettmknight

Looks good from a product perspective

suneox · 2026-08-18T06:26:08Z

Test cases base on current code change

DYNAMIC_ROUTES.TRAVEL_VERIFY_ACCOUNT — verify-account gate before travel (4 entry screens)

Case A.1 — Legacy path: Workspace → Travel → Book travel (beta OFF)

Target: src/components/BookTravelButton.tsx:170, rendered by src/pages/workspace/travel/GetStartedTravel.tsx:41 (screen WORKSPACE.TRAVEL).

Precondition: isTravelVerified beta OFF, account not validated, paid workspace that is not provisioned for travel, admin on a private email domain.

// beta isTravelVerified OFF → falls into the "legacy request-access path"
Onyx.merge('betas', ['all']);
// validated=false → the `!isUserValidated` guard passes → navigate to verify-account
Onyx.merge('account', {validated: false});
// empty travelSettings → isWorkspaceProvisionedForTravel() === false
Onyx.merge('policy_<POLICY_ID>', {travelSettings: {}});
// NOT settable via Onyx: you need a real paid group policy you own (isPaidGroupPolicy + groupPaidPolicies.length >= 1)
// and an admin with a private email domain (getAdminsPrivateEmailDomains).

Steps:

Open the app and log in with the test account.
LHN → Workspaces → pick the workspace → Travel.
Click Book travel.
Verify the Verify account RHP opens (magic-code input).
Verify the URL is /workspaces/<POLICY_ID>/travel/travel-verify-account?policyID=<POLICY_ID> — no ?backTo= anymore.
Click back.

Expected: returns to /workspaces/<POLICY_ID>/travel; both the suffix and ?policyID= are gone from the URL.

Case A.2 — Entry from My Trips (`/travel`)

Target: src/pages/Travel/ManageTrips.tsx:94 (screen TRAVEL.MY_TRIPS).

Precondition: same as A.1.

Onyx.merge('betas', ['all']);
Onyx.merge('account', {validated: false});
Onyx.merge('policy_<POLICY_ID>', {travelSettings: {}});

Steps:

Open the app and log in.
Go to /travel (or LHN → Travel).
Click Book travel.
Click back.

Expected: step 3 opens the Verify account RHP at /travel/travel-verify-account?policyID=<POLICY_ID>; step 4 returns to /travel.

Case A.2b — ⚠️ My Trips opened from the FAB (active route already carries `?policyID=`)

Target: src/pages/inbox/sidebar/FABPopoverContent/menuItems/TravelMenuItem.tsx:50 → ROUTES.TRAVEL_MY_TRIPS.getRoute(policyID) → BookTravelButton.

Precondition: same as A.1, plus a workspace with travel enabled so the FAB shows the Travel item.

Onyx.merge('betas', ['all']);
Onyx.merge('account', {validated: false});
Onyx.merge('policy_<POLICY_ID>', {travelSettings: {}});

Steps:

Log in with the unvalidated account.
Open the FAB → Travel (any path that lands on /travel?policyID=<POLICY_ID>).
Confirm the URL is /travel?policyID=<POLICY_ID>.
Click Book travel.

Expected: the Verify account RHP opens at /travel/travel-verify-account?policyID=<POLICY_ID> with a single policyID param.

⚠️ Note: not fixed in this PR yet. If step 4 opens nothing and the console shows [createDynamicRoute] Query param "policyID" exists in both base path and dynamic suffix, it is not a pass — that is the reported P0. Re-run after the hasPolicyIDInActiveRoute() guard is added.

Case A.3 — Entry from Search (keeps the `?q=` query)

Target: src/pages/Search/EmptySearchView.tsx:273 (screen SEARCH.ROOT).

Precondition: same as A.1, plus Search must be in its empty state so EmptySearchView renders the Book travel button.

Onyx.merge('betas', ['all']);
Onyx.merge('account', {validated: false});
Onyx.merge('policy_<POLICY_ID>', {travelSettings: {}});
// NOT settable via Onyx: the empty state is derived from server search results — use a query that is
// guaranteed to return nothing (e.g. switch the type or filter on a future date range).

Steps:

Open Search so the URL looks like /search?q=type%3Aexpense-report%20sortBy%3Adate%20sortOrder%3Adesc.
Adjust the query until the list is empty and the Book travel button shows.
Click Book travel.
Click back.

Expected: step 3 gives /search/travel-verify-account?q=<original query>&policyID=<POLICY_ID> — both query params present, q is not lost. Step 4 returns to /search?q=<original query> (suffix and policyID stripped, q preserved).

Case A.4 — Beta ON: verify → forward into the enablement stepper after the magic code

Target: src/components/BookTravelButton.tsx:201 and src/pages/Travel/VerifyAccountPage.tsx:44.

Precondition: isTravelVerified beta ON, account not validated, paid workspace not provisioned.

// beta ON → willUseEnablementStepper === true → stepper branch
Onyx.merge('betas', ['all', 'isTravelVerified']);
Onyx.merge('account', {validated: false});
Onyx.merge('policy_<POLICY_ID>', {travelSettings: {}});
// After step 2, TRAVEL_PROVISIONING should hold {nextStepRoute: 'travel/enable/<POLICY_ID>'}

Steps:

Open Workspaces → → Travel.
Click Book travel — the URL should be /workspaces/<POLICY_ID>/travel/travel-verify-account?policyID=<POLICY_ID>.
Enter the magic code from your email (or run Onyx.merge('account', {validated: true})).
Click back on the stepper.

Expected: step 3 replaces (does not stack) the page with the stepper at /travel/enable/<POLICY_ID>; step 4 does not return to the verify-account page, since it was force-replaced out of history.

Case A.5 — ⚠️ Deep link straight into the stepper while unvalidated (entry `TRAVEL.ENABLE`)

Target: src/pages/Travel/EnableTravel/index.tsx:51.

Precondition: isTravelVerified beta ON, account not validated, you are an admin of <POLICY_ID>.

Onyx.merge('betas', ['all', 'isTravelVerified']);
Onyx.merge('account', {validated: false});
// clear any leftover nextStepRoute so this is an entry mount, not a mid-flow one
Onyx.merge('travelProvisioning', {nextStepRoute: null});

Steps:

Log in with the unvalidated account.
Paste /travel/enable/<POLICY_ID> into the address bar and hit Enter.
Confirm you are redirected to /travel/enable/<POLICY_ID>/travel-verify-account?policyID=<POLICY_ID>.
Click back.
Reload (F5) on the URL from step 3.

Expected: step 4 leaves the verify flow — you land on the screen underneath the RHP (Workspaces / Travel) and travel-verify-account is gone from the URL. Step 5 restores the stack with verify-account as an RHP on top of the stepper.

⚠️ Note: this PR does not fix the back loop yet. If step 4 only flashes and returns to the same Verify account page (URL unchanged), it is not a pass — that is the reported P1. Re-run this case after the fix.

Case A.6 — OldRoutes redirect from the old path

Target: src/libs/Navigation/linkingConfig/OldRoutes.ts — '/travel/verify-account': '/travel/travel-verify-account'.

Precondition: account not validated.

Onyx.merge('account', {validated: false});

Steps:

In a new tab, paste /travel/verify-account?policyID=<POLICY_ID> and hit Enter.
Click back.

Expected: the URL rewrites itself to /travel/travel-verify-account?policyID=<POLICY_ID> and the Verify account page renders on top of My Trips (not Not-found, not Home). Back returns to /travel.

Case A.7 — Reload / deep link on the new URL (stack restore)

Precondition: same as A.1.

Onyx.merge('account', {validated: false});

Steps:

Paste /workspaces/<POLICY_ID>/travel/travel-verify-account?policyID=<POLICY_ID> and hit Enter.
Reload (F5).
Click back.

Expected: the Verify account RHP opens over Workspace → Travel and survives the reload; back returns to /workspaces/<POLICY_ID>/travel.

Case A.8 — Invalid entry screen (negative)

Steps:

Paste /settings/profile/travel-verify-account and hit Enter.

Expected: the Verify account page does not open — Not-found (or the getStateFromPath fallback) is shown, and the console logs [getStateFromPath.ts][DynamicRoute] None of the … candidate(s) passed entryScreens validation.

DYNAMIC_ROUTES.TRAVEL_WORKSPACE_CONFIRMATION — create a workspace from Travel upgrade (nested under travel-upgrade)

Case B.1 — My Trips → Travel upgrade → Upgrade

Target: src/pages/Travel/DynamicTravelUpgrade.tsx:37.

Precondition: the account owns no paid group workspace (groupPaidPolicies.length < 1 is what routes Book travel to the upgrade page).

Onyx.merge('account', {validated: true});
// NOT settable via Onyx: groupPaidPolicies is derived from the policy_ collection — use a fresh account
// with no paid workspace, or go straight to the travel-upgrade URL in step 1.

Steps:

Go to /travel and click Book travel (or open /travel/travel-upgrade directly).
Click Upgrade.
Click back.

Expected: step 2 opens the Confirm workspace form at /travel/travel-upgrade/workspace-confirmation; step 3 returns to /travel/travel-upgrade (the Upgrade page — not /travel).

Case B.2 — Entry from Search: `/search/travel-upgrade` (keeps `?q=`)

Precondition: same as B.1.

Onyx.merge('account', {validated: true});

Steps:

Open Search at /search?q=type%3Aexpense-report%20sortBy%3Adate%20sortOrder%3Adesc.
Change the URL to /search/travel-upgrade?q=<same query> and hit Enter.
Click Upgrade.
Click back twice.

Expected: step 3 gives /search/travel-upgrade/workspace-confirmation?q=<same query> with q intact; the two backs go to /search/travel-upgrade?q=… and then /search?q=….

Case B.3 — Entry from Workspace → Travel

Steps:

Open /workspaces/<POLICY_ID>/travel/travel-upgrade.
Click Upgrade.
Click back.

Expected: step 2 gives /workspaces/<POLICY_ID>/travel/travel-upgrade/workspace-confirmation with the Confirm workspace form; step 3 returns to /workspaces/<POLICY_ID>/travel/travel-upgrade.

Case B.4 — Submit the form → workspace created → back on Upgrade confirmation

Target: onSubmit → createDraftWorkspace + createWorkspace → goBack() in WorkspaceConfirmationForTravelPage.tsx (renamed to DynamicWorkspaceConfirmationForTravelPage.tsx in this PR).

Steps:

Get to step 2 of B.1 (/travel/travel-upgrade/workspace-confirmation).
Enter a workspace name, pick a currency, click Confirm.
Click the final confirmation button.

Expected: step 2 returns to /travel/travel-upgrade now showing the Upgrade confirmation state (a paid workspace exists, so isUpgraded === true) instead of the upgrade intro; step 3 leaves the flow.

Case B.5 — Three-level nesting: Currency / Plan type / Avatar crop inside Confirm workspace

Target: DYNAMIC_ROUTES.WORKSPACE_CONFIRMATION_CURRENCY, …_PLAN_TYPE and AVATAR_CROP — all three swap their entry screen to SCREENS.TRAVEL.DYNAMIC_WORKSPACE_CONFIRMATION in this PR.

Steps:

Get to step 2 of B.1.
Click the Currency row, pick a currency.
Click the workspace avatar and choose an image.
If the form exposes Plan type, open it as well.

Expected: step 2 opens /travel/travel-upgrade/workspace-confirmation/currency and returns to the form with the new value; step 3 opens …/workspace-confirmation/avatar-crop and returns to the form; step 4 opens …/workspace-confirmation/plan-type and returns to the form.

Case B.6 — OldRoutes redirect from the old path

Target: '/travel/upgrade/workspace/confirmation': '/travel/travel-upgrade/workspace-confirmation'.

Steps:

In a new tab, paste /travel/upgrade/workspace/confirmation and hit Enter.
Click back.
Repeat step 1 with /travel/upgrade/workspace/confirmation?backTo=/home.

Expected: the URL rewrites to /travel/travel-upgrade/workspace-confirmation and the Confirm workspace form renders (not Not-found, not Home); back returns to /travel/travel-upgrade. In step 3 the redirect keeps ?backTo=/home on the new URL — the param is no longer read, it just must not break anything.

Case B.7 — Reload on the nested URL

Steps:

Paste /travel/travel-upgrade/workspace-confirmation and hit Enter.
Reload (F5).
Click back twice.

Expected: the Confirm workspace form opens on top of the Travel upgrade page and survives the reload; the two backs go to /travel/travel-upgrade and then /travel.