Show configured report columns as fields in single-expense views

[brunovjk]

Explanation of Change

This PR adds support for displaying the report's configured custom columns as read-only fields in single-expense report and expense views.

It also adds the Customize fields option to allow configuring which fields are displayed, reusing the same column preferences used by the report view.

Fixed Issues

$ #101300
PROPOSAL: N/A

Tests

Test Steps

1. Create or open a workspace with custom report columns configured.
2. Create a report with at least one expense.
3. Configure additional columns for the report, such as Category GL code, Exchange rate, or MCC.
4. Verify the configured columns are displayed in the report list view.
5. Open an expense from the report.
6. Verify the configured columns are displayed as read-only fields in the expense view.
7. Open a single-expense report
8. Open the More menu and select Customize fields.
9. Update the displayed fields and verify the changes are reflected in the expense/single-expense view.
10. Verify the regular expense fields and report behavior remain unchanged.

• Verify that no errors appear in the JS console

Offline tests

Same as Test Steps

QA Steps

Same as Test Steps

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Screen.Recording.2026-10-06.at.10.33.27.mov

Android: mWeb Chrome

iOS: Native

102457_ios_native.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

102457_web_chrome.mov

[melvin-bot]

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

1. Look at the code and make sure there are no malicious changes.
2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx bun ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx bun ./scripts/generateTranslations.ts --compare-ref main

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	95.90% <ø> (ø)
src/ROUTES.ts	32.72% <100.00%> (+0.05%)	⬆️
src/SCREENS.ts	100.00% <ø> (ø)
src/components/ColumnsSettingsList.tsx	87.20% <100.00%> (+87.20%)	⬆️
src/components/ColumnsSettingsListItem.native.tsx	100.00% <100.00%> (ø)
src/components/ColumnsSettingsListItem.tsx	100.00% <100.00%> (ø)
...tActionItem/MoneyRequestViewFields/AmountField.tsx	100.00% <100.00%> (ø)
...tionItem/MoneyRequestViewFields/AttendeesField.tsx	100.00% <100.00%> (ø)
...ctionItem/MoneyRequestViewFields/BillableField.tsx	100.00% <100.00%> (ø)
...ctionItem/MoneyRequestViewFields/EditableField.tsx	100.00% <100.00%> (ø)
... and 20 more
... and 12 files with indirect coverage changes

[melvin-bot]

@shawnborton @QichenZhu One of you needs to 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]

[shawnborton]

Let us know when this is ready for @Expensify/design review.

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #102457.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-4c5b547-82e2701-a997c4cd17f08467b6d0270f146238a9ae64c575/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-4c5b547-82e2701-409fa2374d39bfb9dfa5df06f1f5a7ad865d396a/index.html

Web 🕸️
https://102457.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[shawnborton]

This doesn't feel super great when you enable a bunch of fields that don't have values. I wonder if we should have some kind of default "None" value added to these rows that don't actually have values? cc @Expensify/design for thoughts, but the legibility of this feels quite off:

cc @flaviadefaria @trjExpensify for a review too please!

[shawnborton]

The feature itself seems to work really well though!

[flaviadefaria]

This doesn't feel super great when you enable a bunch of fields that don't have values. I wonder if we should have some kind of default "None" value added to these rows that don't actually have values? cc @Expensify/design for thoughts, but the legibility of this feels quite off:

I agree! I think we should add (none) or (blank) to those fields. For some reason, (blank) rings a bell as something we used in Classic, but I might be wrong.

[dannymcclain]

This doesn't feel super great when you enable a bunch of fields that don't have values. I wonder if we should have some kind of default "None" value added to these rows that don't actually have values? cc @Expensify/design for thoughts, but the legibility of this feels quite off:

Yeah I agree. They look especially weird since they're empty and can't be edited. I do think the new input style would help with this, but barring that, I'm not against putting in some kind of none or blank placeholder value here.

[trjExpensify]

Hot take. Should we just park this PR? I see we've merged a PR to add the report level setting to switch to a table view as a preference for one-expense reports. I could see us just starting there.

[shawnborton]

I think some folks felt strongly that if you can customize fields/columns at the report level, you should be able to do it at the expense level as well.

Perhaps you can bring that discussion to Slack, Tom?

[trjExpensify]

Cool. I guess first of all, @flaviadefaria do you think this is still beneficial and necessary in light of the other PR now?

[flaviadefaria]

I see where you’re coming from, but I think there’s room for debate. One could argue that users shouldn’t have to switch views just to see all the expense columns or fields. Personally, I’m fine with parking this for now, but that’s just my perspective. I’m not sure whether we should align with the rest before making that call.

[JS00001]

Fwiw, I think this view is much easier to parse than the single expense, report view, where you'd need to scroll horizontally

[trjExpensify]

Cool, if yous are still for it we can keep it moving.

On the question above, I don't think we should put a placeholder value in the fields, as we don't in the table view for "blank" columns. I do think the page will look nicer with the new in-line inputs, so hopefully we can get to the "post creation" expense forms soon.

[QichenZhu]

Fwiw, I think this view is much easier to parse than the single expense, report view, where you'd need to scroll horizontally

@JS00001, yeah, it's also easier to use on mobile. Do we intend to support mobile? It already mostly works, except for drag-to-reorder.

ios.mov

[JS00001]

That's a good question. I would say we would support mobile here, because we dont have the same horizontal constraint problem that we have for other custom columns on mobile

Thoughts @Expensify/design ?

[dannymcclain]

Yeah I agree that we'd support mobile too.

I don't think we should put a placeholder value in the fields, as we don't in the table view for "blank" columns.

I'm cool with this as well—down to just leave these as they are

[shawnborton]

Yup, all of that works for me. Agree that we'd do this on mobile, too.

[QichenZhu]

@brunovjk, is it possible to support reordering on mobile?

drag-to-reorder.mov

[brunovjk]

@brunovjk, is it possible to support reordering on mobile?

Thanks for the review, I'll check ASAP.

[brunovjk]

Could you take a look now, @QichenZhu? Thanks.

[QichenZhu]

@brunovjk, the latest commit is much bigger than I expected. Could you summarize what changed and why the fix needs to be this large? Thanks!

[brunovjk]

@QichenZhu. I included a few related fixes and cleanups while working on mobile reordering, which made the commit larger than expected.
The mobile fix wires long-press and drag-handle gestures through the existing list-item components, lets the native list handle scrolling, and keeps dropped fields within the selected group. It also introduces web/native row variants. Tests account for 254 of the 471 added lines.
The commit additionally includes an EditableField cleanup, restores wrapping for long merchant names, and handles old preferences missing the required Amount field. Those changes aren't required for mobile reordering.
Would you prefer that I separate those changes and keep this commit focused on the reorder fix? Thanks.

[QichenZhu]

@brunovjk, thanks for the explanation. No need to split them.

[brunovjk]

Im fixing the warning now

[brunovjk]

All yours @QichenZhu