[NO QA] Fix Travel "Let's go" dead-end for half-provisioned workspaces - #93862
Conversation
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40f8b403f5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@madmax330 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] |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d89d6cedf5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Send the default so the Travel-access check runs against the workspace owner's domain, not the acting admin's. | ||
| if (!isUserValidated) { | ||
| setTravelProvisioningNextStep(createDynamicRoute(DYNAMIC_ROUTES.TRAVEL_TCS.getRoute(CONST.TRAVEL.DEFAULT_DOMAIN, activePolicyID))); | ||
| Navigation.navigate(ROUTES.TRAVEL_VERIFY_ACCOUNT.getRoute(CONST.TRAVEL.DEFAULT_DOMAIN, activePolicyID, Navigation.getActiveRoute())); |
There was a problem hiding this comment.
Preserve the terms redirect after validation
When the half-provisioned admin is unvalidated and not in the isTravelVerified beta, this sends them through Travel/VerifyAccountPage, but that page only uses travelProvisioning.nextStepRoute when the beta is enabled; otherwise navigateForwardTo is undefined and validation calls requestTravelAccess() then goes back. In that context the saved terms route is ignored, so after OTP the user still never reaches the accept-terms screen and the workspace remains stuck/reviewing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
if the beta is not enabled they have to requesttravelaccess, so I think this is working as intended, but if you want to check it out @blimpich
|
please ignore the ping @flaviadefaria @madmax330 |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
|
🚧 @blimpich has triggered a test Expensify/App build. You can view the workflow run here. |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Deployed to staging by https://github.com/blimpich in version: 9.4.17-0 🚀
Bundle Size Analysis (Sentry): |
|
🤖 Help site review: no changes required I reviewed the changes in this PR against the help site files under Why: This is an internal navigation/routing bug fix. It corrects where a Workspace Admin lands after clicking Let's go on a workspace that is provisioned for Travel but hasn't accepted the Travel terms yet — routing a validated admin straight to the accept-terms screen, and sending an unvalidated admin to verify their account first. Previously this path dead-ended on a not-found page. The fix only restores the expected flow; it adds no new feature, setting, button, or label. The existing Travel articles (e.g. Enable Expensify Travel on a workspace) document how to enable Travel and the post-enable experience, and they never described the buggy not-found behavior — so there is nothing in the published docs to correct or add. If you'd like a doc that explicitly walks through accepting the Travel terms (the "Let's go" → accept-terms step), let me know and I can draft one. @blimpich, no help site PR was created because no documentation changes are required for this fix. If you disagree and want a docs update, reply with the specifics and I'll open a draft PR. |
|
🚀 Deployed to production by https://github.com/blimpich in version: 9.4.17-3 🚀
|
1 similar comment
|
🚀 Deployed to production by https://github.com/blimpich in version: 9.4.17-3 🚀
|
Explanation of Change
When an admin is on the workspace Travel settings page for a workspace that's been provisioned for Travel but hasn't accepted the Travel terms yet, clicking "Let's go" sends them to the not-found page instead of the Travel terms page.
This PR routes them correctly:
Part of https://github.com/Expensify/Expensify/issues/645887. The Auth companion PR (Expensify/Auth
blimpich-spotnanaSelfManagerFix) fixes the underlying provisioning failure that creates this half‑provisioned state.Fixed Issues
https://github.com/Expensify/Expensify/issues/645887
PROPOSAL:
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
– written by Claude on Ben's behalf