Repository navigation
fix: Widen the date columns of expanded Search groups for past-year dates - #105307
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b9cc32592
ℹ️ 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".
| const submittedColumnSize = shouldShowYearSubmitted ? CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE : CONST.SEARCH.TABLE_COLUMN_SIZES.NORMAL; | ||
| const approvedColumnSize = shouldShowYearApproved ? CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE : CONST.SEARCH.TABLE_COLUMN_SIZES.NORMAL; | ||
| const paidColumnSize = shouldShowYearPaid ? CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE : CONST.SEARCH.TABLE_COLUMN_SIZES.NORMAL; | ||
| const postedColumnSize = shouldShowYearPosted ? CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE : CONST.SEARCH.TABLE_COLUMN_SIZES.NORMAL; | ||
| const exportedColumnSize = shouldShowYearExported ? CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE : CONST.SEARCH.TABLE_COLUMN_SIZES.NORMAL; |
There was a problem hiding this comment.
Include widened dates in the group scroll threshold
On wide web just above the 1024px breakpoint, when users enable several of these historical-date columns plus other fixed-width columns, these assignments add 40px per date while getGroupTableScrollLayout() still calls getTableMinWidth() without any of the new width flags (and therefore keeps its static estimates, such as 72px for Submitted/Approved/Paid/Posted). It can consequently leave shouldScrollHorizontally false after the fixed row width exceeds the viewport; because the ScrollView is then omitted, the rightmost columns overflow or are clipped. Pass the actual date-column minima/flags into the shared scroll-layout calculation so the header and rows enable scrolling at the new widths.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch, fixed!
getGroupTableScrollLayout now takes the group's width flags and counts 102px for each date column that shows the year, so the header and rows switch to horizontal scrolling before those columns get clipped. Groups with only current-year dates keep the same estimate as before.
Added tests for both cases.
|
Expanded groups now use the same date column widths as the ungrouped table ( |
|
@sam5235 did you apply the fix to submitted and approved columns too. |
|
Yes. Each date column (Date, Submitted, Approved, Paid, Posted and Exported) is widened on its own when any expense in the group has a past-year date in that column. The width is also counted when deciding whether the group's table scrolls horizontally. |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb Safari |
garrettmknight
left a comment
There was a problem hiding this comment.
Looks good from a product perspective.
|
🚧 JS00001 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/JS00001 in version: 9.5.27-0 🚀
|
|
No help site update needed. This PR is a layout bug fix that widens date columns in expanded Spend groups so past-year dates no longer get cut off, and no help article describes column widths. |
|
🚀 Deployed to production by https://github.com/blimpich in version: 9.5.27-2 🚀
Bundle Size Analysis (Sentry): |

Explanation of Change
Expanded groups in Spend (e.g. Group by From) only ever sized the Date column for past-year dates.
getGroupColumnWidthFlagscheckedshouldShowYearalone, andTransactionGroupListExpandedand the group sub-header inGroupHeaderpassed onlydateColumnSizedown. So Submitted, Approved, Paid, Posted and Exported stayed at the narrow width (62px), and a date that shows the year ("Oct 22, 2025") was truncated. The ungrouped table already sizes these columns from the same row flags.This is already on production for Submitted and Approved (the production branch, which doesn't include #103956, passes only the Date, Amount and Tax sizes to expanded rows). Paid follows the same pattern as Approved, so it showed the same truncation once it was added.
Changes:
getGroupColumnWidthFlagsalso returnsshouldShowYearSubmitted,shouldShowYearApproved,shouldShowYearPaid,shouldShowYearPostedandshouldShowYearExported, set when any transaction in the group needs the year in that column.TransactionGroupListExpandedpasses the matching column sizes to each row and the flags to its header.GroupHeaderpasses the same flags to its sticky sub-header, so the header and rows stay aligned.Columns whose dates are all from the current year keep the narrow width. Only expanded groups on wide layouts are affected; the ungrouped table and narrow layouts are unchanged.
Fixed Issues
$ #105276
PROPOSAL: #105276 (comment)
Tests
Precondition: an account with paid expenses that were submitted, approved and paid in a previous year.
Offline tests
QA Steps
Same as tests.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)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
The test account has no past-year data, so the browser clock was moved forward a year to make the 2026 dates past-year dates.
After (past-year dates):
Screen.Recording.2026-10-28.at.10.31.01.PM.mp4
After (current-year dates, unchanged):
Screen.Recording.2026-10-28.at.10.35.12.PM.mp4
Before (main):