Web - Spend - Paid date is truncated in table view

@sam5235

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.5.24-5
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #103956
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

Precondition:

There is at least one paid expense from previous year.

Go to staging.new.expensify.com
Go to Spend > Expenses.
Apply the following filters:

Filters > Status > Paid
Filters > Date > Last year
Display > Group by > From
Display > Edit columns > Paid

Expand any group.

Expected Result:

Paid date will be shown completely in table view.

Actual Result:

Paid date is truncated in table view.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7298946_1793204272463.10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7298946

Issue Owner

Current Issue Owner: @sam5235

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9ee0f4c76c3c6caf0cb76543641d04de8c1bde4130702e2593355b89bdc4eb7c

You have been assigned to this deploy blocker because you recently merged this PR: #103956

@JS00001

@JS00001 @FitseTLT @garrettmknight you have been assigned to this deploy blocker because you reviewed the offending PR: #103956

💬 A slack conversation has been started in #expensify-open-source

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Deploy Blocker Analysis

Causing PR: feat: add a Paid column option to the Spend reports table (author sam5235). High confidence. It is the only PR on Deploy Checklist: New Expensify 2026-10-27 that touches these files.

Root cause: The expanded "Group by" table never widens the Paid column for past-year dates. The column stays at 62px, so "Mar 12, 2025" gets cut off. The ungrouped table handles this correctly.

Recommendation: roll forward. The fix is about 15 lines across 3 files. A revert would remove a 20-file feature to fix one column width.

SearchUIUtils.ts getGroupColumnWidthFlags: add shouldShowYearPaid, set it from transaction.shouldShowYearPaid, and include it in the early-break check.
TransactionGroupListExpanded.tsx: pass shouldShowYearPaid to SearchTableHeader, and pass paidColumnSize (WIDE or NORMAL) to each TransactionItemRow.
GroupHeader.tsx: pass shouldShowYearPaid to its sticky SearchTableHeader so the header matches the rows.

If a fix can't land in time, revert the PR.

Investigation details

The Paid column is 102px only when isPaidColumnWide is set, otherwise 62px: styles/utils/index.ts#L2052-L2054.
The date cell uses "MMM d, yyyy" for past-year dates: DateCell.tsx#L43-L46. This is why the repro needs Date = Last year.
The ungrouped table reads shouldShowYearPaid and passes paidColumnSize to the row (TransactionListItemWide.tsx#L144, #L226). Its header does the same (SearchTableHeader.tsx#L718).
Each grouped transaction carries shouldShowYearPaid (SearchUIUtils.ts#L2043). However, neither TransactionGroupListExpanded.tsx nor GroupHeader.tsx reads it. As a result, paidColumnSize is undefined in the row and the cell stays narrow (TransactionItemRowWide.tsx#L170, #L310-L323).
The header and rows are both 62px, so the columns align and the text is just truncated.
Side note: Submitted, Approved, Posted and Exported have the same gap in expanded groups. Based on the code, they likely truncate past-year dates in production already. The PR copied that existing pattern. Fixing them in the same change is optional for this blocker.

view run

@FitseTLT

yeah we can demote, @FitseTLT @sam5235 lets fix this in a follow up please

Thanks, I'll raise the follow-up PR today.

The fix sizes the Paid column in expanded groups the same way as the ungrouped table: getGroupColumnWidthFlags will also check shouldShowYearPaid, and TransactionGroupListExpanded and GroupHeader will pass the size to the rows and the sub-header.

Submitted and Approved have the same gap in expanded groups (likely already on production), and it's the same few lines, so I can fix them in the same PR. Let me know if you'd rather keep it to Paid only.

Proposal

Please re-state the problem that we are trying to solve in this issue.

In Spend > Expenses, when filtering for Paid expenses from a past year (e.g. Status > Paid, Date > Last year), grouping by any attribute (e.g. Group by > From), and displaying the Paid column, expanding a group shows the Paid date truncated with an ellipsis (e.g. Apr 1, ...) instead of showing the full date (Apr 1, 2025).

What is the root cause of that problem?

There are two related root causes introduced with the new Paid column in grouped table view:

In src/libs/SearchUIUtils.ts, inside processTransactionEntry (which computes preprocessing flags during classifyAndPreprocess), the logic checks report?.submitted and report?.approved for past-year dates, but does not check report?.paid:

const report = data[`${ONYXKEYS.COLLECTION.REPORT}${transaction.reportID}`];
if (!ctx.shouldShowYearSubmitted && report?.submitted && DateUtils.doesDateBelongToAPastYear(report.submitted)) {
    ctx.shouldShowYearSubmitted = true;
}
if (!ctx.shouldShowYearApproved && report?.approved && DateUtils.doesDateBelongToAPastYear(report.approved)) {
    ctx.shouldShowYearApproved = true;
}
// report?.paid check is missing!

Consequently, ctx.shouldShowYearPaid is not set to true for transactions in expense search, leaving transaction.shouldShowYearPaid as false.

In grouped layouts (src/components/Search/SearchList/ListItem/TransactionGroupListExpanded.tsx and GroupHeader.tsx), column sizing is derived via getGroupColumnWidthFlags:

getGroupColumnWidthFlags only evaluates transaction.shouldShowYear (for the created date), and ignores shouldShowYearPaid (as well as shouldShowYearSubmitted, shouldShowYearApproved, shouldShowYearPosted, shouldShowYearExported).
TransactionGroupListExpanded.tsx never calculates paidColumnSize or passes it to <TransactionItemRow>. It also omits shouldShowYearPaid when rendering <SearchTableHeader>.
GroupHeader.tsx omits shouldShowYearPaid when rendering <SearchTableHeader>.

Because paidColumnSize is undefined in <TransactionItemRow>, isPaidColumnWide evaluates to false in TransactionItemRowWide.tsx, applying narrow width variables.w62 (62px) instead of wide width variables.w102 (102px). A 4-digit year date cannot fit into 62px and gets truncated with an ellipsis.

What changes do you think we should make in order to solve the problem?

In src/libs/SearchUIUtils.ts:

In processTransactionEntry, add the check for report?.paid:

if (!ctx.shouldShowYearPaid && report?.paid && DateUtils.doesDateBelongToAPastYear(report.paid)) {
    ctx.shouldShowYearPaid = true;
}

In GroupColumnWidthFlags and getGroupColumnWidthFlags, track and return shouldShowYearPaid, shouldShowYearSubmitted, shouldShowYearApproved, shouldShowYearPosted, and shouldShowYearExported across the group's transactions.

In src/components/Search/SearchList/ListItem/GroupHeader.tsx:

Pass shouldShowYearPaid, shouldShowYearSubmitted, shouldShowYearApproved, shouldShowYearPosted, and shouldShowYearExported from getGroupColumnWidthFlags to <SearchTableHeader>.

In src/components/Search/SearchList/ListItem/TransactionGroupListExpanded.tsx:

Derive paidColumnSize (as well as submittedColumnSize, approvedColumnSize, postedColumnSize, and exportedColumnSize) using the flags from getGroupColumnWidthFlags.
Pass shouldShowYearPaid to <SearchTableHeader>.
Pass paidColumnSize (and the other column sizes) to <TransactionItemRow>.

What alternative solutions did you explore? (Optional)

Relying solely on item.shouldShowYearPaid at the individual row level without updating getGroupColumnWidthFlags was considered. However, the table header in GroupHeader.tsx and the rows in TransactionGroupListExpanded.tsx must share the exact same column width calculation to prevent header and column misalignment when horizontal scrolling occurs.

What automated tests can you add to prevent this from re-occurring?

Add a unit test in tests/unit/Search/SearchUIUtilsTest.ts verifying that classifyAndPreprocess and getGroupColumnWidthFlags properly flag shouldShowYearPaid: true when transactions belong to a reimbursed report with a past-year paid date.

Contributor details:

Email: apoorvxs@gmail.com
Upwork Profile: https://www.upwork.com/freelancers/~01f7d7991785f2ee01

@JS00001

@JS00001 this problem already occurs for submitted and approved too should we fix that too?

@FitseTLT

@FitseTLT — to hire @sam5235 on Upwork, add the External label so a job is created and the offer is sent automatically.

yeah lets fix for all of them

Navigation Menu

Repository navigation

Web - Spend - Paid date is truncated in table view #105276

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Deploy Blocker Analysis

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What alternative solutions did you explore? (Optional)

What automated tests can you add to prevent this from re-occurring?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Web - Spend - Paid date is truncated in table view #105276

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Oct 28, 2026

melvin-bot commented on Oct 28, 2026

melvin-bot commented on Oct 28, 2026

melvin-bot commented on Oct 28, 2026

github-actions commented on Oct 28, 2026

MelvinBot commented on Oct 28, 2026

Deploy Blocker Analysis

JS00001 commented on Oct 28, 2026

sam5235 commented on Oct 28, 2026

apoorv-xs commented on Oct 28, 2026

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What alternative solutions did you explore? (Optional)

What automated tests can you add to prevent this from re-occurring?

FitseTLT commented on Oct 28, 2026

melvin-bot commented on Oct 28, 2026

JS00001 commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions