Conversation
getTravelSettings now only returns settings when cardSettings.TRAVEL_US exists, preventing root-level paymentBankAccountID (used by the Expensify Card) from being misinterpreted as Travel Invoicing being enabled. Co-authored-by: Ishpaul Singh <ishpaul777@users.noreply.github.com>
|
I created this PR from an upstream branch since I don't have push access to your fork. To take ownership of this branch and be able to push updates, run: Then you can close this PR and open a new one from your fork. |
|
The only failing check is PR Reviewer Checklist ( This check will resolve once a reviewer posts their reviewer checklist on the PR. No code fix is needed. |
|
@ishpaul777 can we make this ready for review? |
|
The only failing check is All code-related checks (ESLint, typecheck, Prettier, tests, builds, signed commits, etc.) are passing. |
|
i cant do it 😅 it requires write access to mark this ready for review 
|
|
@shubham1206agra 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] |
melvin-bot
bot
requested review from
JmillsExpensify
and removed request for
a team
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| it('Should return true when TRAVEL_US has valid paymentBankAccountID and isEnabled is undefined', () => { | ||
| const cardSettings = { | ||
| // eslint-disable-next-line @typescript-eslint/naming-convention |
There was a problem hiding this comment.
❌ CONSISTENCY-5 (docs)
This eslint-disable-next-line lacks a justification comment explaining why the rule is being disabled. This pattern repeats across all newly added TRAVEL_US test objects in this file.
Add a brief comment explaining the reason, for example:
// TRAVEL_US matches the backend API property name
// eslint-disable-next-line @typescript-eslint/naming-convention
TRAVEL_US: {paymentBankAccountID: 12345},Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
There was a problem hiding this comment.
We don't usually give a reason in tests, so all good.
There was a problem hiding this comment.
Added justification comments to all 21 eslint-disable-next-line directives in the test file:
TRAVEL_USproperties: "TRAVEL_US matches the backend API property name"- Numeric string keys: "Card IDs use numeric string keys from the backend"
Pushed in commit bc532a0.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5f79fdcc78
ℹ️ 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".
| if (!cardSettings?.TRAVEL_US) { | ||
| return undefined; |
There was a problem hiding this comment.
Returning undefined whenever TRAVEL_US is missing breaks the current enable path for workspaces that only have a root-level paymentBankAccountID: WorkspaceTravelInvoicingSection.handleToggle() now always routes to settlement-account setup (hasTravelInvoicingSettlementAccount becomes false), but WorkspaceTravelInvoicingSettlementAccountPage.handleSelectAccount() still reads the same root-level account and treats selecting it as a no-op (value === paymentBankAccountID). In the common single-bank-account case, admins can get stuck unable to turn Travel Invoicing on because no call to setTravelInvoicingSettlementAccount/toggleTravelInvoicing is made.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
I think this actually broke enabling invoicing because we are still flattening the card settings?
|
🚧 @rlinoz 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/rlinoz in version: 9.3.26-0 🚀
|
|
🚀 Deployed to production by https://github.com/puneetlath in version: 9.3.26-8 🚀
|
6 participants
Explanation of Change
getTravelSettings()previously fell back to root-levelcardSettingswhencardSettings.TRAVEL_USwas absent. This meant that if a workspace had a Settlement Bank Account configured for the Expensify Card (root-levelpaymentBankAccountID), the Travel Invoicing toggle would incorrectly show as enabled — even though no Travel Invoicing configuration existed.This PR removes the fallback so
getTravelSettings()only returns data whencardSettings.TRAVEL_USis present, ensuring root-level Expensify Card settings are never misinterpreted as Travel Invoicing settings.Fixed Issues
$ #83038
Tests
TRAVEL_USsettings)Offline tests
No change to offline behavior — this is a logic-only fix for how card settings are interpreted.
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
N/A - logic-only change, no UI modifications
Android: mWeb Chrome
N/A - logic-only change, no UI modifications
iOS: Native
N/A - logic-only change, no UI modifications
iOS: mWeb Safari
N/A - logic-only change, no UI modifications
MacOS: Chrome / Safari
N/A - logic-only change, no UI modifications