[Due for payment 2026-06-23] [$250] Spend- Inline merchant field is not disabled for unreported per diem expense and can be edited

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.78-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89166
Email or phone of affected tester (no customers): injdojsodjdosjdoisd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Workspace has per diem rates.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a per diem expense.
4. Go to Spend > Expenses.
5. Hover over inline merchant field on the per diem expense.
   → Merchant inline field is disabled for per diem expense - Expected.
6. Open the report.
7. Click Report > Remove from report.
8. Click on the inline merchant field on the per diem expense.

Expected Result:

Inline merchant field should be disabled for unreported per diem expense.

Actual Result:

Inline merchant field is not disabled for unreported per diem expense and it can be edited.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7158357_1779230226730.03.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7158357

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056876234388678706
• Upwork Job ID: 2056876234388678706
• Last Price Increase: 2026-06-24

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The inline merchant field editability is determined by canEditRestricted inside getTransactionEditPermissions. For the MERCHANT field, it checks for distance requests and scanning (lines 429-438) but has no per diem check. It then falls through to a generic return at line 464:

return (
    isUnreported ||
    canEditFieldOfMoneyRequest({...})
);

When the expense is unreported, isUnreported short-circuits to true — canEditFieldOfMoneyRequest is never called, so the per diem guard in ReportUtils.ts:4926-4931 is bypassed entirely.

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

Add a per diem check in canEditRestricted for the MERCHANT field in TransactionInlineEdit.ts, alongside the existing distance and scanning checks:

1. Import isPerDiemRequest from @libs/TransactionUtils
2. Add if (isPerDiemRequest(transaction)) { return false; } inside the MERCHANT field block (after the scanning check at line 438)

This mirrors how distance requests are already handled — returning false early before the isUnreported short-circuit can apply.

What alternative solutions did you explore?

Could change the generic fallback at line 464 to always call canEditFieldOfMoneyRequest even for unreported expenses. However, that would change behavior for all field types for unreported expenses, not just per diem merchant. The targeted fix in the MERCHANT block is safer and consistent with how isDistanceRequest is already handled there.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

On the Spend/Expenses page, the inline merchant field is editable for a per diem expense once it's been removed from a report (unreported). It correctly stays disabled while the expense is on a report.

What is the root cause of that problem?

The inline edit permissions are computed in getTransactionEditPermissions inside TransactionInlineEdit.ts. For the merchant field, the only per-field guards are "distance request" and "scanning" — there is no per diem guard. When the expense is reported, the per diem block lives inside canEditFieldOfMoneyRequest (ReportUtils, lines 4926-4931) and correctly returns false. But for unreported expenses, the code short-circuits with isUnreported || canEditFieldOfMoneyRequest(...), so that per diem check is bypassed entirely.

App/src/libs/actions/TransactionInlineEdit.ts

Lines 429 to 439 in 4a67919

	if (field === CONST.EDIT_REQUEST_FIELD.MERCHANT) {
	// Distance expenses cannot have their merchant edited
	if (isDistanceRequest(transaction)) {
	return false;
	}
	// Merchant field shows "Scanning..." during SmartScan
	if (isTransactionScanning) {
	return false;
	}
	}

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

In the MERCHANT branch of canEditRestricted inside getTransactionEditPermissions, add an isPerDiemRequest(transaction) guard alongside the existing isDistanceRequest and isTransactionScanning checks so it returns false for per diem regardless of reported/unreported state. isPerDiemRequest is already exported from @libs/TransactionUtils — just import and use it next to the existing isDistanceRequest import.

App/src/libs/actions/TransactionInlineEdit.ts

Lines 429 to 439 in 4a67919

	if (field === CONST.EDIT_REQUEST_FIELD.MERCHANT) {
	// Distance expenses cannot have their merchant edited
	if (isDistanceRequest(transaction)) {
	return false;
	}
	// Merchant field shows "Scanning..." during SmartScan
	if (isTransactionScanning) {
	return false;
	}
	}

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 05:11:02 UTC.

Proposal

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

On a workspace with per diem rates, the inline merchant field of a per diem expense is correctly disabled in Spend → Expenses while the expense is on a report, but becomes editable once the expense is removed from its report (unreported). It should stay disabled in both states.

What is the root cause of that problem?

Inline-edit permissions for the Spend/report transaction tables are computed by getTransactionEditPermissions → canEditRestricted, added in PR #89166 (merged 2026-05-14). That function re-derives a subset of the transaction-intrinsic field locks per field — distance and SmartScan — but never per diem:

App/src/libs/actions/TransactionInlineEdit.ts

Lines 429 to 438 in 4a67919

	if (field === CONST.EDIT_REQUEST_FIELD.MERCHANT) {
	// Distance expenses cannot have their merchant edited
	if (isDistanceRequest(transaction)) {
	return false;
	}
	// Merchant field shows "Scanning..." during SmartScan
	if (isTransactionScanning) {
	return false;
	}

The canonical rule lives in canEditFieldOfMoneyRequest, which locks AMOUNT, CURRENCY and MERCHANT for a per diem request:

App/src/libs/ReportUtils.ts

Lines 4926 to 4931 in 4a67919

	if (
	(fieldToEdit === CONST.EDIT_REQUEST_FIELD.AMOUNT || fieldToEdit === CONST.EDIT_REQUEST_FIELD.CURRENCY || fieldToEdit === CONST.EDIT_REQUEST_FIELD.MERCHANT) &&
	isPerDiemRequest(transaction)
	) {
	return false;
	}

canEditRestricted only consults that canonical rule through its generic fallback, and the fallback is isUnreported || canEditFieldOfMoneyRequest(...):

App/src/libs/actions/TransactionInlineEdit.ts

Lines 463 to 474 in 4a67919

	return (
	isUnreported ||
	canEditFieldOfMoneyRequest({
	reportAction: parentReportAction,
	fieldToEdit: field,
	isChatReportArchived,
	transaction,
	report: parentReport,
	policy,
	})
	);

The || short-circuits the moment isUnreported is true, so for an unreported expense canEditFieldOfMoneyRequest is never called and its per diem lock is skipped. While the expense is on a report, isUnreported is false, the canonical check runs, and the field is correctly disabled — which is exactly why the bug only appears after Remove from report.

This is not merchant-specific. The AMOUNT branch has the identical shape (split + scanning only, no per diem), and canEditAmount feeds the same kind of inline cell as merchant (TransactionItemRowWide.tsx#L416). So the same short-circuit also leaves the amount cell editable for an unreported per diem expense — a second leak from one root cause. (Currency has no separate inline cell; it rides the amount cell.)

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

Restore the transaction-intrinsic lock the short-circuit bypasses, at the single place it belongs — the top of canEditRestricted — so it mirrors canEditFieldOfMoneyRequest and runs before the isUnreported fallback, covering both leaking cells at once:

 const canEditRestricted = (field: ValueOf<typeof CONST.EDIT_REQUEST_FIELD>) => {
+    // Per diem amount/currency/merchant are derived from the rate and are never editable,
+    // regardless of report state. Mirror canEditFieldOfMoneyRequest so the isUnreported
+    // fallback below can't leak these fields for an unreported per diem expense.
+    if (isPerDiemRequest(transaction) && (field === CONST.EDIT_REQUEST_FIELD.AMOUNT || field === CONST.EDIT_REQUEST_FIELD.MERCHANT)) {
+        return false;
+    }
+
     if (field === CONST.EDIT_REQUEST_FIELD.AMOUNT) {

isPerDiemRequest is already exported from @libs/TransactionUtils — add it to the existing import on L30. It keys off iouRequestType/comment.type and never reads reportID (L269-L275), so it returns the same answer for reported, unreported, and in-flight optimistic per diem transactions; the cell stays disabled across the remove-from-report optimistic transition and any rollback.

I scope the guard to AMOUNT and MERCHANT (not DATE/category/tag/description) because that is exactly the set canEditFieldOfMoneyRequest locks for per diem — no more, no less.

What alternative solutions did you explore? (Optional)

• Add isPerDiemRequest only to the MERCHANT branch. Fixes the reported symptom but leaves the amount inline cell editable for the same unreported per diem expense, since the AMOUNT branch shares the defect. A single guard mirroring the canonical rule fixes both fields at once and keeps the inline layer aligned with the one source of truth.
• Drop the isUnreported || short-circuit and always call canEditFieldOfMoneyRequest. Rejected: the short-circuit is intentional (see the comment block directly above it) — canEditFieldOfMoneyRequest gates on canEditMoneyRequest, which can return false for unreported expenses whose parentReportAction isn't hydrated in Onyx yet (common in Search). Removing it would regress inline editing of every field for those expenses — far wider blast radius than this bug.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[github-actions]

⚠️ @wildan-m 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.