[HOLD https://github.com/Expensify/Expensify/issues/630935] [$250] Toggling on "Enforce Custom Report Names" within Workspaces > Reports overwrites manual edits made to report titles

[brianlee-expensify]

Reproducible in staging?: Y

Reproducible in production?: Y

Issue Reported by : @brianlee-expensify

Slack Conversation: #Expensify Bugs

Expected Result:
Manual edits made to report titles should not change back to the formula-generated report titles once "Enforce Custom Report Names" is toggled on

Actual Result:
Manual edits made to report titles are changing back to the formula-generated report titles once "Enforce Custom Report Names" is toggled on

Actions Performed:

1. Go to Workspaces > Reports > Custom Report Names on Expensify Classic
2. Toggle on "Enforce Custom Report Names" with the formula field set to {report:submit:from} Expense Report {report:startdate}
3. Create a new report and make sure it follows that formula
4. Go back and toggle off "Enforce Custom Report Names"
5. Change the report title to something random
6. Go back and toggle on "Enforce Custom Report Names"
7. Refresh the report page to see the report title revert back to the formula-generated format

MelvinBot analysis here

2026-05-01_11-21-48.2.1.mp4

Recording.2799.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052778496628299696
• Upwork Job ID: 2052778496628299696
• Last Price Increase: 2026-05-08

Issue Owner

Current Issue Owner: @mountiny

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user manually renames a report, the expensify_text_title field on the report's Name Value Pairs (rNVP) is not cleared. This field signals that the report is formula-managed. So when "Enforce Custom Report Names" is later toggled ON, the backend re-applies the formula to all reports that still have expensify_text_title set — including manually renamed ones — overwriting their custom names.

The protection mechanism already exists: removeTitleFieldFromReport sets expensify_text_title: null on a report's rNVP, documented as "Remove title field from report's rNVP when report is manually renamed to indicate that the manual name should be preserved." However, this function is exported but never imported or called anywhere in the codebase. The updateReportName function that handles manual renames only sends {reportID, reportName} to the backend without clearing the rNVP.

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

Wire up removeTitleFieldFromReport inside updateReportName (Report/index.ts:3251): when a report is manually renamed, include the optimistic Onyx updates from removeTitleFieldFromReport (setting expensify_text_title: null) alongside the existing report name update. This signals to the backend that the report's name was manually set and should not be overwritten during formula re-evaluation.

The backend SetReportName/RenameReport handler should also be checked to ensure it clears the text_title rNVP on the server side, so the protection persists beyond the optimistic update.

What alternative solutions did you explore?

An alternative would be to modify the backend's SetPolicyPreventMemberCreatedTitle handler to skip reports whose names were manually changed. However, without the frontend clearing expensify_text_title, the backend has no way to distinguish manually-renamed reports from formula-managed ones. The frontend fix is necessary regardless.

Investigation details

Evidence chain:

1. removeTitleFieldFromReport — exists but never called (grep confirms no imports)
2. updateReportName — manual rename handler, does not touch rNVP
3. setPolicyPreventMemberCreatedTitle — enforcement toggle, sends {policyID, enforced} to backend
4. shouldUpdateTitleField — returns false when expensify_text_title is null, confirming the null-check protection path exists
5. Prior MelvinBot log analysis on Expensify/Expensify#630935 confirmed SetReportNameValuePairs is called with value: null when the enforce toggle fires, re-evaluating the formula for all reports

Related issue: This is the same root cause behind Expensify/Expensify#630935 (customer reports of sporadic title reversions).

---

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.

[melvin-bot]

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

[melvin-bot]

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

[Abdulloh0109]

Proposal

What is the root cause of that problem?

I traced the manual rename flow and found that updateReportName in src/libs/actions/Report/index.ts:3228 issues a RenameReport API call with only reportID and reportName. It never touches the expensify_text_title key in the report's REPORT_NAME_VALUE_PAIRS (rNVP) Onyx collection.

When a report is first created under an active "Enforce Custom Report Names" policy, updateTitleFieldToMatchPolicy in src/libs/ReportTitleUtils.ts:39 writes expensify_text_title: { type: FORMULA, ... } into rNVP. After the user turns enforcement off and manually renames the report, expensify_text_title is never cleared — it stays as type: FORMULA in rNVP both optimistically and on the backend, because updateReportName never signals that the title is now user-managed.

When enforcement is later re-enabled, the backend re-runs its own updateTitleFieldToMatchPolicy equivalent and sees expensify_text_title still typed as FORMULA. It recomputes the formula and overwrites the report name. On the next page refresh, Onyx receives the server-authoritative data and the manual edit is gone.

The evidence that this path was anticipated but not wired up: removeTitleFieldFromReport (src/libs/ReportTitleUtils.ts:70) is a purpose-built helper that sets expensify_text_title: null to flag a manual edit. It is exported but has zero call sites anywhere in the codebase. Likewise, shouldUpdateTitleField (src/libs/ReportTitleUtils.ts:92) correctly guards formula reapplication with a !reportTitleField check, but is also exported and never called.

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

This is a frontend fix. Two small, targeted changes are required:

1. Wire up removeTitleFieldFromReport inside updateReportName (src/libs/actions/Report/index.ts:3228).

The optimisticData array in updateReportName should be extended with the rNVP updates returned by removeTitleFieldFromReport(reportID). This sets expensify_text_title: null optimistically the moment the user saves a manual rename, signalling to both the local store and (on the next API response) the backend that this report should no longer be formula-managed. The failureData array should restore the previous expensify_text_title value (fetched via getTitleFieldFromRNVP(reportID) before the update) so a failed rename rolls back correctly. The RenameReport API command parameters do not need to change; the rNVP null is already persisted by Onyx's offline queue.

2. Guard updateTitleFieldToMatchPolicy with a shouldUpdateTitleField check (src/libs/ReportTitleUtils.ts:39).

After the early-return for a missing reportTitleField (line 48), add a check using getTitleFieldFromRNVP(reportID) — if it returns null (manually edited, cleared by removeTitleFieldFromReport), return an empty array and skip the rNVP overwrite. This prevents updateTitleFieldToMatchPolicy from restoring FORMULA type over a manually-edited report when called again (e.g., on a new expense added to the same report).

Files touched: src/libs/actions/Report/index.ts, src/libs/ReportTitleUtils.ts. Files NOT touched: MoneyRequestBuilder.ts (its guard at line 1085 already works correctly once rNVP is null), any policy action files, any backend endpoints. Platforms affected: all (web, iOS, Android).

What alternative solutions did you explore? (Optional)

No other proposals exist on this issue yet.

I considered adding the null-out directly inside maybeUpdateReportNameForFormulaTitle in MoneyRequestBuilder.ts:1085, but that function is only invoked during IOU creation/editing — it would not cover the case where the page is refreshed and the backend re-applies the formula name independently of any IOU action.

I also considered patching only the backend RenameReport endpoint, but since that code lives outside the App repo, a pure frontend fix that uses the already-built removeTitleFieldFromReport helper is both faster and correct: Onyx's offline queue guarantees the null reaches the server even on flaky networks.