Skip to content

[Due for payment 2026-10-30] [$175] Add a More menu option to switch single-expense reports between expense view and table view #102910

Open

Description

@melvin-bot

Problem

When a report has only one expense, we open it in the single-expense view. When it has more than one, we open it in the table view. Admins and approvers have told us the switch between these two layouts is confusing:

  • Each time they open a report, they stop to work out which layout they're looking at and where things are.
  • Some approvers find it easier to review in the table view, where expense-level fields appear as table columns.
  • Users also mix up whether they're looking at an expense or a report.

Proposal

On single-expense reports, add an option to the More menu that switches the layout:

  • In the single-expense view, the option says Switch to table view.
  • In the table view, the option says Switch to expense view.

The option shows only on reports with one expense. Reports with more than one expense keep opening in the table view.

When a user picks an option, we save it as their default. Every single-expense report they open after that uses the view they chose, until they switch back.

This setting applies only to the user who picks it. It isn't a workspace setting.

Please refer to this POC build here to see the feature in action: https://100966.pr-testing.expensify.com/

Screenshots / Mockups

Here's a proof of concept for how this should look when viewing a single-expense expense report:

2026-10-05_11-20-14.mp4

Next steps

  • Confirm the final copy and where the option goes in the More menu.
  • Save the selection on the user's account so it applies on every device.
  • Respect the saved view everywhere a single-expense report opens (Reports tab, chats, search results, and links).

Reported in Slack.

Upwork Automation - Do Not Edit
Issue OwnerCurrent Issue Owner: @daledah

Activity

  1. melvin-bot commented on Oct 2, 2026

    @melvin-bot
    Author

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

  2. added
    ExternalAdded to denote the issue can be worked on by a contributor
    on Oct 2, 2026
  3. melvin-bot commented on Oct 2, 2026

    @melvin-bot
    Author

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

  4. changed the title [-]Add a More menu option to switch single-expense reports between expense view and table view[/-] [+][$175] Add a More menu option to switch single-expense reports between expense view and table view[/+] on Oct 2, 2026
  5. melvin-bot commented on Oct 2, 2026

    @melvin-bot
    Author
  6. self-assigned this
    on Oct 2, 2026
  7. mohamad-shafeez commented on Oct 2, 2026

    @mohamad-shafeez

    Proposal

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

    Users find the automatic layout switching between single-expense view and table view disorienting when reviewing single-expense reports. They need a persistent option in the More menu to view single-expense reports in table view across all their devices.

    What is the root cause of that problem?

    1. In src/libs/MoneyRequestReportUtils.ts, shouldDisplayReportTableView(report, transactions) evaluates !isReportTransactionThread(report) && !isSingleTransactionReport(report, transactions), forcing single-transaction reports into the single-expense view regardless of user preference.
    2. There is no user-level Name-Value Pair (NVP) to persist this display preference across devices (ONYXKEYS.NVP_SINGLE_EXPENSE_TABLE_VIEW).
    3. MoneyReportHeaderSecondaryActions.tsx lacks a contextual toggle item for single-transaction reports.

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

    1. User Preference Storage (ReportLayout.ts & ONYXKEYS.ts):

      • Add NVP_SINGLE_EXPENSE_TABLE_VIEW: 'nvp_expensify_singleExpenseTableView' in src/ONYXKEYS.ts.
      • In src/libs/actions/ReportLayout.ts, implement setSingleExpenseTableView(shouldUseTableView: boolean, previousValue?: boolean) using the standard API.write(WRITE_COMMANDS.SET_NAME_VALUE_PAIRS, ...) with optimistic and failure rollback data.
    2. More Menu Toggle (MoneyReportHeaderSecondaryActions.tsx):

      • Subscribe to ONYXKEYS.NVP_SINGLE_EXPENSE_TABLE_VIEW.
      • When isSingleTransactionReport(moneyRequestReport, nonPendingDeleteTransactions) is true, insert a toggle action:
        • Label: shouldUseTableView ? translate('reportLayout.viewAsSingleExpense') : translate('reportLayout.viewAsTable')
        • Icon: shouldUseTableView ? Expensicons.Receipt : Expensicons.Table
        • onSelected: Call setSingleExpenseTableView(!shouldUseTableView, shouldUseTableView).
    3. Centralized Layout Resolution (src/libs/MoneyRequestReportUtils.ts):

      • Update shouldDisplayReportTableView to accept a shouldUseTableViewForSingleExpense preference and respect it for single-transaction reports (while still returning false for transaction threads).
      • Pass the preference through the main entry points: MoneyRequestReportView.tsx, ReportActions.tsx, search views, and related RHP paths.
      • Suppress the wide receipt panel (WideRHPReceiptPanel.tsx) when the single-expense table view preference is enabled.
    4. Navigation Edge Case (OneTransactionThreadRedirectHandler.tsx):

      • MoneyRequestReportPreview can navigate using childReportID, which may represent the transaction thread rather than the parent report.
      • The redirect bypass must be scoped carefully so that enabling table view on the parent single-expense report does not break legitimate transaction-thread deep links or navigation flows.
    5. Localization & Unit Tests:

      • Add keys for reportLayout.viewAsTable and reportLayout.viewAsSingleExpense (English source + existing translation process).
      • Add unit tests for the preference action, the updated layout resolver, menu visibility, and the redirect behavior.

    What alternative solutions did you explore? (Optional)

    • Creating a dedicated backend command: Unnecessary — Expensify standardizes user preferences via SET_NAME_VALUE_PAIRS.
    • Client-only local storage: Rejected because the setting must persist and sync across devices.
  8. melvin-bot commented on Oct 2, 2026

    @melvin-bot
    Author

    📣 @mohamad-shafeez! 📣
    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.
      Screen Shot 2022-11-16 at 4 42 54 PM
      Format:
    Contributor details
    Your Expensify account email: <REPLACE EMAIL HERE>
    Upwork Profile Link: <REPLACE LINK HERE>
    
  9. mohamad-shafeez commented on Oct 2, 2026

    @mohamad-shafeez

    Contributor details
    Your Expensify account email: [email protected]
    Upwork Profile Link: https://www.upwork.com/freelancers/~01ede4d9cba5c66ae0

  10. 65 remaining items

  11. melvin-bot commented on Oct 21, 2026

    @melvin-bot
    Author

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  12. melvin-bot commented on Oct 22, 2026

    @melvin-bot
    Author

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  13. jponikarchuk commented on Oct 22, 2026

    @jponikarchuk

    Deploy Blocker #104676 was identified to be related to the PR #103703 that attempted to fix this issue.

  14. jponikarchuk commented on Oct 22, 2026

    @jponikarchuk

    Deploy Blocker #104678 was identified to be related to the PR #103703 that attempted to fix this issue.

  15. jponikarchuk commented on Oct 22, 2026

    @jponikarchuk

    Deploy Blocker #104681 was identified to be related to the PR #103703 that attempted to fix this issue.

  16. melvin-bot commented on Oct 22, 2026

    @melvin-bot
    Author

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  17. jponikarchuk commented on Oct 22, 2026

    @jponikarchuk

    Deploy Blocker #104682 was identified to be related to the PR #103703 that attempted to fix this issue.

  18. melvin-bot commented on Oct 22, 2026

    @melvin-bot
    Author

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  19. changed the title [-][$175] Add a More menu option to switch single-expense reports between expense view and table view[/-] [+][Due for payment 2026-10-30] [$175] Add a More menu option to switch single-expense reports between expense view and table view[/+] on Oct 23, 2026
  20. melvin-bot commented on Oct 23, 2026

    @melvin-bot
    Author

    @daledah

    The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2026-10-30. 🎊

    Contributor+ Checklist: The following checklist (instructions) needs to be completed before this issue can be closed:

    • [@daledah] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.
    • [] Link the GH issue for creating/updating the regression test once above steps have been agreed upon.

    If no checklist is needed for this issue, use the K2 [no checklist button].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

DailyKSv2ExternalAdded to denote the issue can be worked on by a contributorNewFeatureSomething to build that is a new item.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions