[Due for payment 2026-03-30] [$250] Expenses - Uploaded receipt is not displayed when create manual expense

[jponikarchuk]

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: v9.3.40-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84407
Email or phone of affected tester (no customers): gocemate+b215490600@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: Other

Action Performed:

1. Create workspace
2. Go to workspace chat and submit manual expense with receipt> Complete the process

Expected Result:

Receipt should bedisplayed in the expense

Actual Result:

Receipt is not displayed in the expense

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ZhenjaHorbach

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034292512038776449
• Upwork Job ID: 2034292512038776449
• Last Price Increase: 2026-03-18

[melvin-bot]

@grgia recently merged #84407, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @MonilBhavsar (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 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:

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

[melvin-bot]

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #84407 - "Block restricted field edits on closed expense reports" by @grgia (High confidence)
Related Issues: #81493 (the issue that PR #84407 was supposed to fix)

Recommendation: REVERT

PR #84407 adds !isClosedReport(moneyRequestReport) to the canEditFieldOfMoneyRequest function for the RECEIPT field. This prevents editing/deleting receipts on closed reports. However, this change appears to have an unintended side effect: it prevents receipts from being properly displayed when manual expenses are created in workspaces where workflows are disabled (which causes reports to immediately transition to CLOSED status).

The issue is reproducible on staging (where PR #84407 is deployed) but not on production (where it is not yet deployed), confirming this PR as the cause.

While the original issue #81493 that PR #84407 fixed was valid (preventing "Delete receipt" button on closed reports), the implementation is too aggressive and breaks receipt display for a common workflow scenario.

Labels: DeployBlockerCash label should remain (this is a frontend bug affecting the App)

📋 Detailed Analysis

Evidence

1. Timeline: PR Block restricted field edits on closed expense reports #84407 merged on 2026-03-18T07:47:33Z, present in staging deploy 9.3.40-0
2. Reproducibility: Issue is reproducible on staging (has PR Block restricted field edits on closed expense reports #84407) but not production (doesnt have it)
3. Code change: The PR added !isClosedReport(moneyRequestReport) as the first condition in the RECEIPT field check in canEditFieldOfMoneyRequest()
4. Affected scenario: The issues reproduction steps (create workspace → submit manual expense with receipt) match the exact scenario where workflows might be disabled, causing reports to close immediately

Verification

• File modified: src/libs/ReportUtils.ts, specifically the canEditFieldOfMoneyRequest function
• Change location: Line 4941 adds !isClosedReport(moneyRequestReport) && to the RECEIPT field return statement
• Impact: When a report is closed (which happens immediately when workflows are disabled), canEditFieldOfMoneyRequest returns false for RECEIPT field

Root Cause

When workflows are disabled on a workspace (approval mode = OPTIONAL), expense reports immediately transition to CLOSED state (statusNum=2). PR #84407 added a check to prevent receipt editing on closed reports. While this successfully prevents the "Delete receipt" button from appearing on closed reports (the original bug), it appears to have an unintended consequence where receipts uploaded during manual expense creation in closed reports are not properly displayed.

The canEditReceipt variable (calculated using canEditFieldOfMoneyRequest for RECEIPT field) is used in MoneyRequestReceiptView.tsx line 171-172, and while it should only control editing capability, the closed report check may be interfering with proper receipt rendering or upload completion in the manual expense creation flow.

[MelvinBot]

Proposal

Problem

PR #84407 introduced a regression where receipts are not properly editable (and may appear non-functional) when creating manual expenses on workspaces where the expense report auto-closes.

Root Cause

PR #84407 added !isClosedReport(moneyRequestReport) to the RECEIPT field check in canEditFieldOfMoneyRequest at src/libs/ReportUtils.ts:4941. This was intended to block the "Delete receipt" button on closed reports (fix for #81493), but the condition is too broad — it blocks ALL receipt operations (edit, replace, and delete) on closed reports, not just the delete action.

Why admins are affected: The canEditMoneyRequest function (line 4780-4782) lets admins and managers bypass the isClosedReport check — they can always edit coding fields. But the RECEIPT-specific check at line 4941 re-introduces !isClosedReport without the admin/manager exemption. This means an admin creating an expense on a workspace where the report auto-closes (Submit & Close) will have canEditReceipt = false.

How this manifests:

• canEditReceipt = false makes the ReceiptEmptyState disabled and thumbnail-sized (disabled={!canEditReceipt}, isThumbnail={!canEditReceipt} at MoneyRequestReceiptView.tsx:401,410)
• The receipt image becomes readonly (readonly={readonly || !canEditReceipt} at line 472)
• The compose bar's "Add/Replace receipt" option is hidden (ReportActionCompose.tsx:246)

Why staging-only: In production (without PR #84407), the RECEIPT check doesn't have the isClosedReport gate, so admin users can interact with receipts normally on closed reports.

Solution

The isDeleteAction parameter already exists in canEditFieldOfMoneyRequest and is already used in the RECEIPT block at line 4947: (isDeleteAction ? isRequestor : true). The fix is to scope the isClosedReport check to only apply when isDeleteAction is true:

Change line 4941 in src/libs/ReportUtils.ts from:

!isClosedReport(moneyRequestReport) &&

To:

!(isDeleteAction && isClosedReport(moneyRequestReport)) &&

This preserves the original fix from PR #84407 (blocking receipt deletion on closed reports via TransactionReceiptModalContent.tsx:131 which passes isDeleteAction=true) while allowing receipt viewing and editing on closed reports.

What did you do to verify your analysis?

1. Traced the full code path: canEditMoneyRequest (line 4780-4782) → admins bypass isClosedReport → canEditFieldOfMoneyRequest RECEIPT block (line 4939-4948) → PR Block restricted field edits on closed expense reports #84407's !isClosedReport blocks all receipt ops
2. Verified that canEditReceipt controls editability props (disabled, readonly, isThumbnail) in MoneyRequestReceiptView.tsx
3. Confirmed that isDeleteAction=true is only passed from TransactionReceiptModalContent.tsx:131 for the delete receipt use case, while MoneyRequestReceiptView.tsx:172 and ReportActionCompose.tsx:245 don't pass it
4. Checked that policy configurations (Submit & Close, disabled workflows) can produce reports with statusNum=CLOSED via getExpenseReportStateAndStatus

---

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.