[$250] Category - Employee can't edit Category in the approved expense

[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: v9.3.97-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-37535/folder/13176818/41237262/1457879571
Email or phone of affected tester (no customers): lekima20+61306@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Employee create and submit an expense with no category to the workspace chat
• Admin approve the Employee's expense

1. Open https://staging.new.expensify.com
2. Employee navigate to the workspace chat
3. Tap on the approved expense at precondition

Expected Result:

Verify the category is editable by the employee

Actual Result:

The category isn't clickable by the employee

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7170181_1780467734008.Recording__2173.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7170181

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062061440161665902
• Upwork Job ID: 2062061440161665902
• Last Price Increase: 2026-06-03

[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/689edc3b131ad17c99f0bd1ef2ea762fb42e27c3aafc26932447c17dfaaa1d42

[MelvinBot]

Proposal

Confidence: Medium. The code mechanism is confirmed; whether the "Expected Result" is correct is a product decision (see the caveat below).

TL;DR: The category is unclickable because once the admin approves, canEditMoneyRequest returns false for the submitter. That value gates the category field's interactive/shouldShowRightIcon props, so the row stops responding to taps.

What is the root cause of that problem?

For an employee (submitter, not admin/manager) viewing an approved expense report, canEditMoneyRequest returns false because its final condition requires !isReportApproved(...). Category is a non-restricted field, so its editability is decided entirely by this function.

That value flows straight into the UI: canEdit in MoneyRequestView becomes false, and the category row's interactive={canEdit} / shouldShowRightIcon={canEdit} make it non-clickable — exactly the reported symptom.

Evidence + the product caveat

• canEditMoneyRequest short-circuits to true for admins/managers (line 4769) — which is why the admin can still edit coding fields after approval, but the submitter cannot.
• The discrepancy: the function's own doc comment says a requestor on an expense report can edit "as long as it's not settled" — it does not list "approved" as a blocker (lines 4702–4705). The actual code blocks on isReportApproved and isSettled and isClosedReport. So either the code over-restricts the submitter, or the doc comment is stale.
• The existing unit tests assert that approved reports are not editable by the submitter for the restricted/move fields, but I found no test asserting the submitter's ability to edit category on an approved-but-unsettled report — so the test suite doesn't lock in either interpretation for this case.
• Caveat — this hinges on a product decision. If approved expenses are intended to be locked for submitters, then the current behavior is correct and the BrowserStack test's "Expected Result" is outdated. The doc comment is the strongest evidence that submitters should retain coding-field edits until settlement, which is why I lean toward this being a real regression — but please confirm intended behavior before merging a code change.

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

If the intended behavior is "submitter can edit the category until the report is settled" (per the doc comment):

• Relax the submitter gate in canEditMoneyRequest so an approved-but-unsettled expense report is still editable by the requestor.
• This stays safe for sensitive fields: restricted fields (amount, currency, merchant, date, receipt, etc.) have a second approval/settlement guard in canEditFieldOfMoneyRequest (if (isSettled || isReportApproved) return false), so they would remain locked. Only non-restricted coding fields (category, tag, description) would become editable again — matching what the admin/manager already get.
• Add a unit test in tests/unit/canEditFieldOfMoneyRequestTest.ts covering "submitter can edit category on an approved (unsettled) expense report" to lock in the contract.

If instead approved expenses are meant to be locked for submitters, the fix is to update the BrowserStack test case expectation rather than the code.

What alternative solutions did you explore? (Optional)

Scoping the change at the field level (only unlock category/tag for submitters on approved reports) instead of relaxing canEditMoneyRequest broadly — but since the restricted-field guard at line 4967 already protects sensitive fields, the simpler canEditMoneyRequest change achieves the same end result.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92476) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[aswin-s]

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

On all platforms (Android, iOS, Web), after an admin approves an employee's expense submitted to a workspace chat, the employee can no longer tap the Category field on the expense detail view. Expected: the Category field should remain editable by the employee (the requestor) on an approved expense, since category is a coding field — not a restricted/financial one.

What is the root cause of that problem?

In src/components/ReportActionItem/MoneyRequestView.tsx at line 350, the canEdit flag is derived from a single call to canEditMoneyRequest:

const canEdit = isMoneyRequestAction(parentReportAction)
    && canEditMoneyRequest(parentReportAction, transaction, isChatReportArchived, moneyRequestReport, policy)
    && isEditable;

In src/libs/ReportUtils.ts, canEditMoneyRequest (line 4711) returns false for a non-admin, non-manager employee (requestor) once the expense report is approved — its final guard at line 4783 is:

return !isReportApproved({report: moneyRequestReport}) && !isSettled(moneyRequestReport) && !isClosedReport(moneyRequestReport) && isRequestor;

For an approved report this evaluates to false, so canEdit becomes false. The Category MenuItemWithTopDescription at lines 1083–1084 then receives interactive={false} and shouldShowRightIcon={false}, making it non-interactive.

Meanwhile, the per-field function canEditFieldOfMoneyRequest (line 4918) already distinguishes restricted fields (amount, currency, merchant, date, receipt, distance, distance rate, reimbursable, report, billable) from coding fields (category, tag, description). It gates restricted fields with an isSettled || isReportApproved check at line 4967, but for non-restricted fields it returns true as soon as the base canEditMoneyRequest check passes. The file already uses this pattern for amount and merchant at lines 366–373 — those rows pass the specific fieldToEdit through canEditFieldOfMoneyRequest instead of using the global canEdit — but the category, tag, and description rows use the coarser canEdit flag, which is why they break on approval while amount/merchant remain correctly blocked.

The critical point is that canEditMoneyRequest is also used as the sole gate in src/hooks/useShowNotFoundPageInIOUStep.ts (line 68):

shouldShowNotFoundPage = !isMoneyRequestAction(reportAction)
    || !canEditMoneyRequest(reportAction, transaction, false, iouReport, policy);

This hook guards all IOU edit step routes (amount, currency, distance, receipt, etc.). Loosening canEditMoneyRequest to allow requestors on approved reports would cause those edit step screens to render instead of showing a Not Found page — even though canEditFieldOfMoneyRequest would still block the actual save. The fix must not touch canEditMoneyRequest.

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

The fix is confined to src/components/ReportActionItem/MoneyRequestView.tsx. Introduce a canEditCodingFields boolean alongside the existing canEdit at line 350, calling canEditFieldOfMoneyRequest with CONST.EDIT_REQUEST_FIELD.CATEGORY:

// line 350 — existing, unchanged
const canEdit = isMoneyRequestAction(parentReportAction)
    && canEditMoneyRequest(parentReportAction, transaction, isChatReportArchived, moneyRequestReport, policy)
    && isEditable;

// NEW — add immediately after line 350
const canEditCodingFields = isEditable
    && canEditFieldOfMoneyRequest({
        reportAction: parentReportAction,
        fieldToEdit: CONST.EDIT_REQUEST_FIELD.CATEGORY,
        isChatReportArchived,
        transaction,
        report: moneyRequestReport,
        policy,
    });

canEditFieldOfMoneyRequest with CONST.EDIT_REQUEST_FIELD.CATEGORY will:

1. Call canEditMoneyRequest internally (blocks deleted actions, settled reports, closed reports, non-requestors who are not admin/manager).
2. See that CATEGORY is not in restrictedFields and return true immediately — without the isReportApproved rejection that canEditMoneyRequest applies to requestors.

Then replace canEdit with canEditCodingFields on the category, tag, and description rows:

// Category row (lines 1083–1084) — change canEdit → canEditCodingFields
interactive={canEditCodingFields}
shouldShowRightIcon={canEditCodingFields}

// Tag row (equivalent lines for tag MenuItemWithTopDescription) — same swap
interactive={canEditCodingFields}
shouldShowRightIcon={canEditCodingFields}

// Description row — same swap
interactive={canEditCodingFields}
shouldShowRightIcon={canEditCodingFields}

canEditFieldOfMoneyRequest is already imported in MoneyRequestView.tsx (used at lines 369, 373, and further down for date, distance, etc.), and CONST.EDIT_REQUEST_FIELD is already available, so no new imports are needed.

No changes to src/libs/ReportUtils.ts are needed. No changes to useShowNotFoundPageInIOUStep.ts are needed. The existing edit step route guards remain untouched.

Why restricted fields remain blocked: Amount, merchant, date, distance, distance rate, receipt are each already gated by their own canEditFieldOfMoneyRequest call with the specific field (lines 366–446). Those calls hit the isSettled || isReportApproved guard inside canEditFieldOfMoneyRequest at line 4967 and return false — the change above does not touch those rows.

Why useShowNotFoundPageInIOUStep is unaffected: The hook at line 68 calls canEditMoneyRequest directly, which is not modified. An employee on an approved report still gets shouldShowNotFoundPage = true for all IOU edit step routes, exactly as before.

No platform-specific twins — MoneyRequestView.tsx and ReportUtils.ts are shared across Android/iOS/Web.

What alternative solutions did you explore? (Optional)

Alternative A: drop !isReportApproved({report: moneyRequestReport}) from the final return in canEditMoneyRequest (line 4783) so requestors retain base edit permission on approved reports. Rejected: canEditMoneyRequest is also used by useShowNotFoundPageInIOUStep as the sole gate for IOU edit step routes (amount, currency, distance, etc.). Loosening it would allow employees to navigate into those edit step screens on approved reports — the screens would render and only fail at the point of save, which is a confusing UX regression. Restricted fields are blocked at the save level by canEditFieldOfMoneyRequest, but the navigation guard would be bypassed.

Alternative B: add a isCodingField bypass inside canEditMoneyRequest that returns true when the field is category/tag/description. Rejected: canEditMoneyRequest has no fieldToEdit parameter, so this would require changing its signature and spreading field-awareness into a function whose job is base-permission — duplicating logic already present in canEditFieldOfMoneyRequest.

[melvin-bot]

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

[melvin-bot]

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

[ReaperOAK]

Proposal

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

After an admin approves an employee's expense, the employee (submitter/requestor) cannot tap the Category field on the expense detail view to edit it, even though Category is a non-restricted coding field that should remain editable post-approval per the documented intent of canEditMoneyRequest.

What is the root cause of that problem?

The root cause is in src/libs/ReportUtils.ts in the canEditMoneyRequest function. Its final return for the requestor path (line ~4783) is:

return !isReportApproved({report: moneyRequestReport}) && !isSettled(moneyRequestReport) && !isClosedReport(moneyRequestReport) && isRequestor;

Because isReportApproved is true for an approved report, this returns false — blocking the submitter from editing any field, including non-restricted coding fields like Category.

This single false value propagates through two separate blocking paths:

Path 1 — UI interactivity (src/components/ReportActionItem/MoneyRequestView.tsx, line ~350):

const canEdit = isMoneyRequestAction(parentReportAction)
    && canEditMoneyRequest(parentReportAction, transaction, isChatReportArchived, moneyRequestReport, policy)
    && isEditable;

canEdit = false causes the Category row (~lines 1083–1084) to render with interactive={false} and shouldShowRightIcon={false}.

Path 2 — Edit route guard (src/hooks/useShowNotFoundPageInIOUStep.ts, line ~68):

shouldShowNotFoundPage = !isMoneyRequestAction(reportAction)
    || !canEditMoneyRequest(reportAction, transaction, isChatReportArchived, moneyRequestReport, policy)
    || ...

Even if the Category row were made interactive, navigating to the edit screen would immediately render a "Not Found" page because canEditMoneyRequest still returns false.

The function canEditFieldOfMoneyRequest (line ~4918) already exists and correctly distinguishes restricted fields (amount, currency, merchant, date, receipt, etc.) from coding fields (category, tag, description). It gates restricted fields with isSettled || isReportApproved, but for coding/non-restricted fields it defers to the base canEditMoneyRequest check — which is exactly the broken gate. So canEditFieldOfMoneyRequest does call canEditMoneyRequest internally as its prerequisite; patching only MoneyRequestView.tsx without fixing canEditMoneyRequest would be a no-op.

The doc comment for canEditMoneyRequest (lines ~4702–4705) explicitly states a requestor can edit "as long as it's not settled" — approval is not listed as a blocker. The code over-restricts by adding !isReportApproved.

The fix must be in src/libs/ReportUtils.ts in canEditMoneyRequest, removing !isReportApproved({report: moneyRequestReport}) from the requestor's return condition. This unblocks both MoneyRequestView.tsx (via canEdit → category row interactive) and useShowNotFoundPageInIOUStep.ts (edit route accessible) simultaneously, with no view-layer changes needed.

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

File: src/libs/ReportUtils.ts

Locate the final return of canEditMoneyRequest for the requestor path and remove the !isReportApproved guard:

// BEFORE (line ~4783):
return !isReportApproved({report: moneyRequestReport}) && !isSettled(moneyRequestReport) && !isClosedReport(moneyRequestReport) && isRequestor;

// AFTER:
return !isSettled(moneyRequestReport) && !isClosedReport(moneyRequestReport) && isRequestor;

No imports are required — this is a single condition removal in an existing function.

Why this works:

• canEditMoneyRequest

[moxw]

Proposal

What is the root cause of that problem?

The category edit path is still gated by the generic money-request edit permission instead of a category-specific permission.

In MoneyRequestView, the category row uses the coarse canEdit boolean:

canEdit = canEditMoneyRequest(...) && isEditable

For an employee/requestor on an approved expense report, canEditMoneyRequest() returns false because its final requestor branch blocks approved reports. That makes the category row render with interactive={false}.

There is also a second blocker: IOURequestStepCategory uses useShowNotFoundPageInIOUStep(), and that hook also checks only canEditMoneyRequest(). So even if the row were made clickable, the category edit page would render Not Found for the same approved-report requestor case.

canEditFieldOfMoneyRequest() is the right abstraction, but today it cannot fix this by itself because it calls canEditMoneyRequest() before reaching the non-restricted-field logic. For category, the field-level branch is unreachable once the report is approved.

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

Make category editing field-aware instead of loosening the generic canEditMoneyRequest() permission globally.

1. Update canEditFieldOfMoneyRequest() in src/libs/ReportUtils.ts so CONST.EDIT_REQUEST_FIELD.CATEGORY can be edited by the requestor on approved expense reports when the report is not settled/closed, while still preserving the existing deleted-action, failed-transaction, archived, admin/manager, policy/workflow, and non-requestor checks.

The important boundary is:

• CATEGORY: allowed for the requestor after approval, but not after settlement/closed.
• Restricted fields like amount, currency, merchant, date, receipt, distance, reimbursable, billable, and report: still blocked on approved reports.
• Do not simply remove !isReportApproved() from canEditMoneyRequest(), because that function is used as a broad route/edit affordance gate for many fields.

2. In src/components/ReportActionItem/MoneyRequestView.tsx, add a dedicated canEditCategory using canEditFieldOfMoneyRequest({fieldToEdit: CONST.EDIT_REQUEST_FIELD.CATEGORY, ...}).

Use canEditCategory for the category row’s:

interactive
shouldShowRightIcon
copyValue / copyable decision

This keeps amount/date/merchant/tax/etc. on their existing field-specific restrictions instead of making the whole expense editable.

3. Make useShowNotFoundPageInIOUStep() field-aware, or add a category-specific guard in IOURequestStepCategory.

For the category step, validate with:

canEditFieldOfMoneyRequest({
    reportAction,
    fieldToEdit: CONST.EDIT_REQUEST_FIELD.CATEGORY,
    transaction,
    report: iouReport,
    policy,
})

instead of only canEditMoneyRequest(). Other edit steps can keep the existing generic guard unless they need their own field-specific exceptions.

4. Add regression coverage:

• Requestor on approved expense report: canEditFieldOfMoneyRequest(CATEGORY) returns true.
• Same approved report: restricted fields like AMOUNT, DATE, and MERCHANT remain false.
• Settled or closed report: category remains false.
• Category edit route does not show Not Found for the approved-report requestor case.
• Manual regression: employee submits an expense without category, admin approves it, employee opens the expense and can select a category; amount/date/merchant remain non-editable.

What alternative solutions did you explore? (Optional)

Removing the approved-report check from canEditMoneyRequest() would unblock the category row and route, but it is too broad. That helper is used by generic edit affordances and edit-step route guards, so loosening it would make approved expenses appear editable beyond the category case. A field-aware permission keeps this fix scoped to category while preserving the existing restrictions for financial and report-state-sensitive fields.