Fix footer Reset falling back to a stale selected-expense currency - #97767
Conversation
effectiveDefaultCurrency fell back to metadataCurrency (the search snapshot's currency) and then to the currency of whatever expense was selected. For a fresh no-workspace account metadataCurrency is empty until a search populates it, so Reset picked the selected expense's currency instead of the user's live payment currency. Fall back to usePreferredCurrency() instead, which reads the live payment currency from Onyx.
…ing for the footer fallback
…lling-card currency
|
@ahmedGaber93 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] |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / SafariScreen.Recording.2026-08-08.at.9.34.09.AM.mov |
|
Bug: Changing the user's currency correctly updates the search total currency, but the total amount is not recalculated. Screen.Recording.2026-08-06.at.6.50.27.PM.mov |
…e loaded figures' denomination The default footer currency now tracks the live payment currency, so it can move away from the currency the snapshot's server-converted figures are denominated in (e.g. after changing Preferences > Payment currency). Key the conversion machinery off the display target (picker choice or default) versus each row's denomination instead of only picker choices, and label unconverted figures with their own denomination.
… from the loaded figures' denomination" This reverts commit ccf4730.
…plicit Reset The default footer currency tracks the live payment currency, so it can move away from the currency the loaded figures are denominated in (e.g. after changing Preferences > Payment currency). Label unconverted totals with the figures' own denomination instead of the default's symbol, make Reset pass the default through as an explicit selection, and gate conversion on the chosen currency differing from the figures' denomination rather than from the default, so resetting to a just-changed payment currency converts the total to it.
Reset selects the current default explicitly, and the conversion gate compares the chosen currency against the loaded figures' denomination so that selection fires a conversion when the default moved after fetch. The unconverted-label changes are dropped.
The gate compared the chosen currency against only the first selected entry's denomination, so a mixed-denomination selection whose first row already matched the chosen currency never converted the remaining rows. Check all selected entries (and reports on the Reports search), skipping report-view rows like areAllSelectedEntriesConverted does.
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
This reverts commit ef93dee.
…s untouched" This reverts commit 22dd7dc.
…on an explicit Reset" This reverts commit d6fee1a.
…ffers from the figures The picker's Reset/default currency now comes from the active policy's output currency (the personal policy's for accounts without a workspace, which is what Preferences > Payment currency edits), mirroring the currency the server converts search figures to when the query has no explicit target. Reset passes that currency through as an explicit selection instead of clearing the choice, and the existing default chain keeps comparing it against the figures' denomination, so the conversion machinery runs exactly when the loaded figures are in another currency.
getTargetCurrency falls back to the active policy's currency and then USD, so drop the personal-policy tier. Accounts without a workspace have their personal policy as the active policy, which the test setup now reflects.
Reset always passes a currency now, so the undefined variant is unreachable.
|
Fixed it. Screen.Recording.2026-08-07.at.7.33.27.PM.mov |
|
@ahmedGaber93 fixed that. Please re-review. |
mountiny
left a comment
There was a problem hiding this comment.
Thanks for the follow up, looks good to me
|
@mountiny can you merge this then? |
|
Yes, slipped though with the new verify peer action you cant merge it immediately 🤦 |
|
🚧 mountiny 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/mountiny in version: 9.4.52-0 🚀
|
|
🤖 No help site changes required. This PR is an internal bug fix: it corrects the Reset action in the Spend page's selection-footer currency selector so it falls back to the account's payment currency ( I searched
Since no article describes the affected behavior, and the fix simply makes the UI behave as intended, there is nothing to update on the help site. No draft docs PR was created. |
|
🚀 Deployed to production by https://github.com/roryabraham in version: 9.4.52-11 🚀
Bundle Size Analysis (Sentry): |
Explanation of Change
The footer's Reset/default currency fell back to the selected expense's own currency, so after changing Preferences > Payment currency, Reset kept restoring the old currency.
The Reset/default currency now comes from the active policy's output currency (the personal policy's for accounts without a workspace, which is what Preferences > Payment currency edits). This mirrors the currency the server converts search figures to when the query has no explicit target.
Reset also passes that currency through as an explicit selection instead of clearing the choice. The existing default chain compares it against the currency the loaded figures are denominated in, so the conversion machinery runs exactly when the figures are in another currency and stays idle otherwise.
Also changed
SearchResultsProvider'sdefaultSearchInfo.currencyfrom''toundefinedso an unset search currency is alwaysundefined.Fixed Issues
$ #97583
PROPOSAL:
Tests
Screen.Recording.2026-08-07.at.7.33.27.PM.mov
Offline tests
Not affected — the payment currency is read from already-persisted Onyx data (
PERSONAL_POLICY_IDand the personal policy), same as before; no new network requests are introduced.QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, 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.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