[CFI] [$250] Make clicking on an expense in a multi expense report preview take you to the expense you clicked

[iwiznia]

Context https://expensify.slack.com/archives/C03U7DCU4/p1778857848633499

Additional context on the View button request from a feedback call: https://expensify.slack.com/archives/C07NMDKEFMH/p1779731862108089

Problem

When you have a multi expense report, you can scroll in the preview to see all the expenses, but then no matter where you click, you are taken to the report page. This is unexpected as users would think it takes you to the expense you selected

Solution

Change it so that:

• Clicking on the expense takes you to the expense itself
• If on mobile, it would push 2 pages: the report one and the expense one, so going back would take you to the report
• In order to make it easier to navigate to the report itself, add a grey view button to the report actions

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056653847843997298
• Upwork Job ID: 2056653847843997298
• Last Price Increase: 2026-05-26

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @shawnborton (NewFeature)

[melvin-bot]

📣 @Ilya0527! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[KJ21-ENG]

Proposal

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

In a multi-expense report preview, clicking any expense preview opens the parent report instead of opening the expense that was clicked. This makes the carousel look item-specific while behaving like a single report link.

What is the root cause of that problem?

The multi-expense preview uses one report-level press handler for both the outer card and every transaction item.

MoneyRequestReportPreview defines openReportFromPreview() and passes it to MoneyRequestReportPreviewContent as the wrapper onPress. It also passes that same callback to each carousel TransactionPreview via onPreviewPressed. TransactionPreview then wraps the expense card in a pressable and calls the provided callback, so a click on an individual expense still runs the parent report navigation.

There is already separate expense-level navigation in MoneyRequestReportTransactionList: it finds or creates the transaction thread report for the selected transaction, marks it as an expense RHP target, stores the active transaction IDs for prev/next navigation, and navigates to ROUTES.SEARCH_REPORT. The preview carousel is not using that path.

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

Add an expense-specific click path for carousel items in MoneyRequestReportPreview.

Concretely:

• Extract/reuse the transaction-thread navigation from MoneyRequestReportTransactionList into a shared helper/hook that accepts the expense report, report actions, ordered transactions, and the clicked transactionID.
• In MoneyRequestReportPreview, pass an openExpenseFromPreview(transactionID) callback to each TransactionPreview instead of openReportFromPreview.
• For wide layouts, have that callback open the clicked transaction thread in the RHP with the same behavior as the report transaction table (setActiveTransactionIDs, setOptimisticTransactionThread or optimistic thread creation, markReportIDAsExpense, then navigate to ROUTES.SEARCH_REPORT).
• For narrow/mobile layouts, first navigate to the report route and then push the transaction thread route, using the report route as the expense route's backTo. That preserves the requested back-stack behavior: back from the expense returns to the report, then back returns to the chat.
• Keep the outer report preview wrapper opening the report itself, so clicks outside an individual expense still behave as report navigation.
• Make the report action area always provide a grey View button for report navigation in addition to any primary report action where needed, instead of relying on the whole preview card as the only way to open the report.

The fix should keep long-press/context-menu behavior intact and avoid changing single-expense MoneyRequestAction behavior.

What alternative solutions did you explore? (Optional)

Only changing TransactionPreview to derive its own navigation would work, but it would duplicate report-table transaction-thread setup and risks diverging from existing prev/next and optimistic-thread behavior. Reusing/extracting the existing money-request report transaction navigation keeps the preview and report table consistent.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jayeshmangwani (External)

[wildan-m]

Proposal

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

In a multi-expense report preview (the carousel that appears in chat when a report contains more than one expense), clicking on any individual expense card in the carousel takes the user to the report page instead of to the specific expense they clicked. Users expect that clicking an expense should open that expense.

The desired behavior is:

• Clicking on an expense in the carousel opens that specific expense.
• On narrow layouts (mobile), this should push two screens — the report on top of the chat, and then the expense on top of the report — so the back button returns the user to the report.
• A separate grey "View" button is added to the report-preview action row so users still have a clear way to open the parent report itself.

What is the root cause of that problem?

In the multi-expense report preview, every transaction card in the carousel is wired to a single shared press handler, openReportFromPreview, which always navigates to the parent IOU report (ROUTES.EXPENSE_REPORT_RHP on wide layouts, ROUTES.REPORT_WITH_ID on narrow). It never inspects the transaction the user actually pressed.

openReportFromPreview is created here:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Lines 103 to 119 in 58eb366

	const openReportFromPreview = useCallback(() => {
	if (!iouReportID || contextMenuRef.current?.isContextMenuOpening) {
	return;
	}
	startSpan(`${CONST.TELEMETRY.SPAN_OPEN_REPORT}_${iouReportID}`, {
	name: 'MoneyRequestReportPreview',
	op: CONST.TELEMETRY.SPAN_OPEN_REPORT,
	});
	// Small screens navigate to full report view since super wide RHP
	// is not available on narrow layouts and would break the navigation logic.
	if (isSmallScreenWidth) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(iouReportID, undefined, undefined, Navigation.getActiveRoute()));
	} else {
	Navigation.navigate(ROUTES.EXPENSE_REPORT_RHP.getRoute({reportID: iouReportID, backTo: Navigation.getActiveRoute()}));
	}
	}, [iouReportID, isSmallScreenWidth]);

It is then passed as onPreviewPressed to every TransactionPreview rendered by the carousel's renderItem:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Lines 128 to 150 in 58eb366

	const renderItem: ListRenderItem<Transaction> = ({item}) => (
	<TransactionPreview
	chatReportID={chatReportID}
	action={getIOUActionForReportID(item.reportID, item.transactionID)}
	contextAction={action}
	reportID={item.reportID}
	isBillSplit={isSplitBillAction}
	isTrackExpense={isTrackExpenseAction}
	contextMenuAnchor={contextMenuAnchor}
	isWhisper={isWhisper}
	isHovered={isHovered}
	iouReportID={iouReportID}
	containerStyles={transactionPreviewContainerStyles}
	shouldDisplayContextMenu={shouldDisplayContextMenu}
	transactionPreviewWidth={reportPreviewStyles.transactionPreviewCarouselStyle.width}
	transactionID={item.transactionID}
	reportPreviewAction={action}
	onPreviewPressed={openReportFromPreview}
	shouldShowPayerAndReceiver={shouldShowPayerAndReceiver}
	shouldHighlight={!!newTransactionIDs?.has(item.transactionID)}
	originalReportID={originalReportID}
	/>
	);

Inside TransactionPreview, when onPreviewPressed is provided, it becomes the onPress of the wrapping PressableWithoutFeedback, so the whole card forwards the click to the same report-level navigator regardless of which transaction was tapped:

App/src/components/ReportActionItem/TransactionPreview/index.tsx

Lines 109 to 141 in 58eb366

	if (onPreviewPressed) {
	return (
	<PressableWithoutFeedback
	onPress={shouldDisableOnPress ? undefined : props.onPreviewPressed}
	onPressIn={() => canUseTouchScreen() && ControlSelection.block()}
	onPressOut={() => ControlSelection.unblock()}
	onLongPress={showContextMenu}
	shouldUseHapticsOnLongPress
	accessibilityLabel={isBillSplit ? translate('iou.split') : translate(getExpenseTypeTranslationKey(getTransactionType(transaction)))}
	accessibilityHint={convertToDisplayString(requestAmount, requestCurrency)}
	sentryLabel={CONST.SENTRY_LABEL.TRANSACTION_PREVIEW.CARD}
	>
	<TransactionPreviewContent
	{...props}
	action={iouAction}
	isBillSplit={isBillSplit && !transaction?.comment?.originalTransactionID}
	chatReport={chatReport}
	personalDetails={personalDetails}
	transaction={transactionPreview}
	transactionRawAmount={transactionRawAmount}
	report={report}
	violations={violations}
	offlineWithFeedbackOnClose={offlineWithFeedbackOnClose}
	navigateToReviewFields={navigateToReviewFields}
	areThereDuplicates={areThereDuplicates}
	sessionAccountID={sessionAccountID}
	walletTermsErrors={walletTerms?.errors}
	routeName={route.name}
	isReviewDuplicateTransactionPage={isReviewDuplicateTransactionPage}
	shouldHighlight={shouldHighlight}
	/>
	</PressableWithoutFeedback>
	);

The information needed to navigate to the right expense is already available — the carousel computes the per-transaction IOU action with getIOUActionForReportID(item.reportID, item.transactionID) when building renderItem. That action's childReportID is the transaction thread report, which is exactly the screen a user expects to see when clicking the card. The bug is that this per-transaction action is only used to populate the preview content, not the press handler.

Additionally, there is no dedicated way to open the parent IOU report once per-card clicks navigate to individual expenses. The existing "View" button inside ReportPreviewActionButton.tsx only renders in the fallback branch when no primary report-preview action (Submit / Approve / Pay / Export / Add Expense) is available:

App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewActionButton.tsx

Lines 231 to 237 in 58eb366

	return (
	<Button
	text={translate('common.view')}
	onPress={openReportFromPreview}
	sentryLabel={CONST.SENTRY_LABEL.REPORT_PREVIEW.VIEW_BUTTON}
	/>
	);

So for any report that is in an actionable state, there is currently no visible affordance for "open the parent report", which is why the spec asks for a new always-present grey button.

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

Three coordinated changes, all in the MoneyRequestReportPreview area:

1. Make each carousel card navigate to its own expense, not to the parent report.

   In src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx, change the renderItem callback so that the onPreviewPressed it passes to each TransactionPreview is a per-item handler instead of the shared openReportFromPreview. The per-item handler is built from the same getIOUActionForReportID(item.reportID, item.transactionID) value the component already computes, mirroring the established pattern used by the single-transaction case in src/components/ReportActionItem/MoneyRequestAction.tsx (the onMoneyRequestPreviewPressed callback). Concretely, for each transaction:

   • If the per-transaction IOU action has a childReportID, navigate to that transaction thread report. On wide layouts open it in the RHP via ROUTES.SEARCH_REPORT; on narrow layouts use ROUTES.REPORT_WITH_ID so it pushes onto the navigation stack. This reuses the exact branching that MoneyRequestAction already uses, so behavior matches the standalone-expense case.
   • If childReportID is missing, fall back to createTransactionThreadReport and navigate to the newly created thread, again exactly as MoneyRequestAction does today. This avoids a dead click for transactions whose thread has not yet been materialized.
   • Preserve the existing telemetry span and the contextMenuRef.current?.isContextMenuOpening guard inside the new per-item handler so context-menu long-press behavior and Sentry tracing are unchanged.

2. On narrow layouts, push the report screen first, then the expense, so back returns to the report.

   In the same per-item handler, when the layout is narrow (isSmallScreenWidth), first navigate to the parent IOU report with ROUTES.REPORT_WITH_ID.getRoute(iouReportID, ...) and then navigate to the transaction thread on top. Using two sequential Navigation.navigate calls (rather than a single push) means the navigation stack ends with chat → report → expense, which gives the back-button behavior the spec describes: "going back would take you to the report". On wide layouts, do not double-push — the expense thread opens in the RHP next to the report, and the user can dismiss the RHP to return to the report cleanly, so a single ROUTES.SEARCH_REPORT navigation is enough.

3. Always render a grey "View" button in the report-preview action row.

   In src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewActionButton.tsx, stop treating the "View" button as a fallback that only appears when no other report-preview action is available. Instead, render it as a secondary action that is always shown alongside whatever primary button (SubmitActionButton, ApproveActionButton, PayActionButton, ExportWithDropdownMenu, ButtonWithDropdownMenu for Add Expense) is currently rendered, and remove the fallback Button at the bottom of renderButton so it is no longer duplicated. The "View" button keeps onPress={openReportFromPreview} so it navigates to the parent IOU report exactly as today, and uses Button's secondary / grey styling (success={false} plus the existing secondary style props on Button) to match the design ask of a non-primary grey button. The container View already constrains width via buttonMaxWidth and styles.flex1; wrapping the primary button and the new View button in a row layout with appropriate gap keeps both within the existing action-row footprint.

No changes are needed to TransactionPreview itself, because it already forwards the onPreviewPressed prop as the card's onPress. The carousel level is the right place to specialize the handler, because the carousel is the only call site where the press target is a specific transaction inside a report-level preview.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/91042-multi-expense-preview-per-item-nav?expand=1

What alternative solutions did you explore? (Optional)

• Specialize the press handler inside TransactionPreview itself by checking action?.childReportID directly. This was rejected because TransactionPreview is also used from MoneyRequestAction (single-expense preview in chat) where the parent already computes a richer handler that handles split-bill, thread-creation, and RHP-vs-stack branching. Centralizing the decision in MoneyRequestReportPreview/index.tsx keeps TransactionPreview a dumb prop forwarder and avoids accidentally regressing the single-expense path.
• Use Navigation.push once with a fully-built navigation state instead of two sequential Navigation.navigate calls on narrow layouts. This was rejected because the existing report-preview code base reaches the equivalent stack via plain Navigation.navigate and React Navigation's stack-merge behavior, which is the convention used by sibling callers (e.g. MoneyRequestAction). Two Navigation.navigate calls keeps the code consistent with how the rest of the file navigates today.
• Replace the existing fallback "View" button with the always-present one (a single button that swaps onPress based on state). This was rejected because the fallback branch's "View" exists when there is genuinely nothing else to do on the report; once the new always-on View button exists, that fallback collapses into the same button and the special-case branch can simply be removed without behavior loss.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022056653847843997298

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @aswin-s Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.