[$250] Expense - Unexpected error after changing approved report name as submitter

[mitarachim]

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.5-0-staging
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #79524
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11, Chrome | iPhone SE 3rd generation, iOS 26.2 | Samsung A15, Android 16
App Component: Other

Action Performed:

Preconditions:

• The user is an admin of a workspace.

• The workspace has 1 member (submitter) and 2 members (Approver 1, Approver 2).

• Approvals default workflow is set as follows:

• Expenses from: Everyone

• First approver: Approver 1

• Second approver: Approver 2

1. Go to https://staging.new.expensify.com
2. Sign in as the submitter, create and submit 3 expenses to the workspace.
3. In an incognito tab, sign in as Approver 1.
4. Open the submitter’s expense report. Hold 1 expense, then approve only the unheld expenses.
5. As the submitter, open the non held expense report.
6. Click on the header, then click on Title, rename it, and save.

Expected Result:

A submitter should be able to rename an approved report without triggering errors

Actual Result:

When the submitter changes the name of an approved report, an unexpected error occurs.
(If the report was renamed by an admin first, and then the submitter tries to rename it, the error is not shown.)

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7054336_1768945037664.issue.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022014059875777161174
• Upwork Job ID: 2014059875777161174
• Last Price Increase: 2026-03-02

Issue Owner

Current Issue Owner: @marufsharifi

[melvin-bot]

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[melvin-bot]

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

[imadirtydog]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-20 16:06:49 UTC.

Proposal

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

When a submitter changes the name of an approved report (after the first approver has approved in a multi-approver workflow), an unexpected error occurs (404 report not found). The submitter should not be able to rename a report that is in the approval workflow.

What is the root cause of that problem?

The isReportFieldDisabled function checks for settled, closed, and approved reports, but does not check for reports in the "processing" state (submitted and awaiting approval):

App/src/libs/ReportUtils.ts

Lines 4424 to 4442 in 0fdd406

	function isReportFieldDisabled(report: OnyxEntry<Report>, reportField: OnyxEntry<PolicyReportField>, policy: OnyxEntry<Policy>): boolean {
	if (isInvoiceReport(report)) {
	return true;
	}
	const isReportSettled = isSettled(report?.reportID);
	const isReportClosed = isClosedReport(report);
	const isTitleField = isReportFieldOfTypeTitle(reportField);
	const isAdmin = isPolicyAdmin(policy);
	const isApproved = isReportApproved({report});
	if (!isAdmin && (isReportSettled || isReportClosed || isApproved)) {
	return true;
	}
	if (isTitleField) {
	return !reportField?.deletable;
	}
	return reportField?.type === CONST.REPORT_FIELD_TYPES.FORMULA;
	}

function isReportFieldDisabled(report: OnyxEntry<Report>, reportField: OnyxEntry<PolicyReportField>, policy: OnyxEntry<Policy>): boolean {
    // ...
    if (!isAdmin && (isReportSettled || isReportClosed || isApproved)) {
        return true;
    }
    // ...
}

The problem is that isReportApproved only returns true when stateNum === APPROVED (2) and statusNum === APPROVED (3). In a multi-approver workflow, after the first approver approves, the report remains in the "processing" state (stateNum === 1, statusNum === 1), not the "approved" state. This means non-admins can still attempt to edit report fields, but the backend rejects the operation.

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

Primary Solution (Recommended)

Add isProcessingReport(report) to the condition in isReportFieldDisabled:

App/src/libs/ReportUtils.ts

Line 4433 in 0fdd406

if (!isAdmin && (isReportSettled || isReportClosed || isApproved)) {

Current code:

if (!isAdmin && (isReportSettled || isReportClosed || isApproved)) {
    return true;
}

Proposed fix:

if (!isAdmin && (isReportSettled || isReportClosed || isApproved || isProcessingReport(report))) {
    return true;
}

Affected Components

This change affects all usages of isReportFieldDisabled:

File	Usage	Impact
ReportDetailsPage.tsx:824	Title field editability	Title disabled for non-admins during processing
MoneyReportView.tsx:111-113	Filters visible report fields	Custom fields hidden for non-admins during processing
MoneyRequestViewReportFields.tsx:114-116	Filters visible report fields	Custom fields hidden for non-admins during processing
EditReportFieldPage.tsx:67	Edit page access	Shows "Not Found" for non-admins during processing

Note on Custom Fields Visibility (Out of Scope)

During investigation, it was observed that isReportFieldDisabled is used in MoneyReportView and MoneyRequestViewReportFields to filter out (hide) fields rather than just disable them:

const enabledReportFields = sortedPolicyReportFields.filter(
    (reportField) => !isReportFieldDisabled(report, reportField, policy) || reportField.type === CONST.REPORT_FIELD_TYPES.FORMULA,
);

This means custom report fields already disappear from the UI for non-admins when reports are settled, closed, or approved. Adding isProcessingReport extends this existing behavior to processing reports, making it consistent across all non-open report states.

Whether fields should disappear vs. be shown as read-only is a separate UX consideration outside the scope of this issue. I find it a bit weird personally.

---

Secondary Solution (Alternative)

If a more targeted fix is preferred in order to limit the changes, add the check only in ReportDetailsPage.tsx:

1. Add isProcessingReport to the imports:

App/src/pages/ReportDetailsPage.tsx

Lines 55 to 108 in 0fdd406

	import {
	canDeleteCardTransactionByLiabilityType,
	canDeleteTransaction,
	canEditReportDescription as canEditReportDescriptionUtil,
	canJoinChat,
	canLeaveChat,
	canWriteInReport,
	createDraftTransactionAndNavigateToParticipantSelector,
	getAvailableReportFields,
	getChatRoomSubtitle,
	getDisplayNamesWithTooltips,
	getIcons,
	getOriginalReportID,
	getParentNavigationSubtitle,
	getParticipantsAccountIDsForDisplay,
	getParticipantsList,
	getReportDescription,
	getReportFieldKey,
	getReportForHeader,
	isAdminOwnerApproverOrReportOwner,
	isArchivedNonExpenseReport,
	isCanceledTaskReport as isCanceledTaskReportUtil,
	isChatRoom as isChatRoomUtil,
	isChatThread as isChatThreadUtil,
	isClosedReport,
	isCompletedTaskReport,
	isConciergeChatReport,
	isDefaultRoom as isDefaultRoomUtil,
	isExpenseReport as isExpenseReportUtil,
	isFinancialReportsForBusinesses as isFinancialReportsForBusinessesUtil,
	isGroupChat as isGroupChatUtil,
	isHiddenForCurrentUser,
	isInvoiceReport as isInvoiceReportUtil,
	isInvoiceRoom as isInvoiceRoomUtil,
	isMoneyRequestReport as isMoneyRequestReportUtil,
	isMoneyRequest as isMoneyRequestUtil,
	isPolicyExpenseChat as isPolicyExpenseChatUtil,
	isPublicRoom as isPublicRoomUtil,
	isReportFieldDisabled,
	isReportFieldOfTypeTitle,
	isRootGroupChat as isRootGroupChatUtil,
	isSelfDM as isSelfDMUtil,
	isSystemChat as isSystemChatUtil,
	isTaskReport as isTaskReportUtil,
	isThread as isThreadUtil,
	isTrackExpenseReportNew as isTrackExpenseReportUtil,
	isUserCreatedPolicyRoom as isUserCreatedPolicyRoomUtil,
	isWorkspaceChat as isWorkspaceChatUtil,
	isWorkspaceMemberLeavingWorkspaceRoom as isWorkspaceMemberLeavingWorkspaceRoomUtil,
	navigateBackOnDeleteTransaction,
	navigateToPrivateNotes,
	shouldDisableRename as shouldDisableRenameUtil,
	shouldUseFullTitleToDisplay,
	} from '@libs/ReportUtils';

import {
    // ... existing imports
    isProcessingReport,
    isReportFieldDisabled,
    // ... rest
} from '@libs/ReportUtils';

2. Modify the isFieldDisabled check:

App/src/pages/ReportDetailsPage.tsx

Line 824 in 0fdd406

const isFieldDisabled = isReportFieldDisabled(report, titleField, policy);

Current code:

const isFieldDisabled = isReportFieldDisabled(report, titleField, policy);

Proposed fix:

const isFieldDisabled = isReportFieldDisabled(report, titleField, policy) || (!isPolicyAdminUtil(policy) && isProcessingReport(report));

Downsides of Secondary Solution

1. Incomplete coverage: Does not protect EditReportFieldPage - users can still access the edit form via direct URL (/r/{reportID}/edit/policyField/{policyID}/text_title) and trigger the backend error
2. Inconsistent behavior: Processing reports would behave differently from approved/settled/closed reports (title editable in some views but not others)
3. Requires additional fixes: Would need similar changes in EditReportFieldPage.tsx and potentially other entry points for complete protection
4. Maintenance burden: Logic is duplicated across multiple files instead of being centralized in isReportFieldDisabled
   Overall, I find it a bit clunky, but it would safely resolve the issue, without making significant changes.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[NicMendonca]

@Krishna2323 bump on reviewing these proposals ^

[Krishna2323]

Thanks for the bump, will review this tomorrow morning.