You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expense - No option to remove report field from report after deleting from workspace settings #101805
Version Number: 9.4.91-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:#100735 Email or phone of affected tester (no customers):sjodjoijsonjoinj@gmail.com Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Mac 26.5 / Chrome App Component: Money Requests
Action Performed:
Precondition:
Create a text type report field.
Go to staging.new.expensify.com
Go to workspace chat.
Create an expense.
Go to workspace settings > Report fields.
Click on the report field and delete it.
Go back to workspace chat.
Open the report.
Expected Result:
User can remove report field from report after deleting it from workspace settings.
Actual Result:
There is no option to remove report field from report after deleting it from workspace settings.
👋 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:
Identify the pull request that introduced this issue and revert it.
PR #100735 replaced the report field rows (which navigated to the report field editor page) with inline inputs, and the editor page's three-dots Delete menu was the only UI that can remove a report field from a report — so the deletion path is now unreachable. Four sibling deploy blockers come from the same PR, so reverting it clears all five at once, and nothing merged after it depends on the code it added.
Assigned: @Gonals and @daledah (approving reviewers of #100735) are already assigned; the PR author is the MelvinBot automation account. Labels: No changes. DeployBlockerCash stays (App-side regression, fix is in Expensify/App); DeployBlocker was not present, so nothing to remove.
A report field deleted from the workspace intentionally stays on the report: getAvailableReportFields in ReportUtils.ts:4964-4966 — "Get the report fields that are attached to a report. These will persist even if a field is deleted from the policy." So the row keeps rendering and the user needs an explicit way to remove it.
The only UI that calls deleteReportField is the three-dots menu on the report field editor page: DynamicEditReportFieldPage.tsx:136-147 (deleteReportField is invoked at line 112; the only other call site in src/ is the action definition itself).
On production, tapping a report field in the report opened that page: MoneyRequestViewReportFields.tsx:57-86, with the navigation at line 74. MoneyReportView.tsx had the same row and the same navigation for one-expense reports.
All three are in Show up to three report fields per row and edit them inline #100735's file list, and it is the only PR on this checklist that touches the report field rendering path (the report-field files changed between production and staging are the ones this PR added or rewrote).
After the PR, the only remaining navigations to DYNAMIC_ROUTES.EDIT_REPORT_FIELD in src/ are for the title field (AvatarWithDisplayName.tsx:240 and DynamicReportDetailsPage.tsx:1011), and the title field is explicitly excluded from the delete menu — so no non-title field can reach Delete any more.
Revert feasibility: the APIs the PR introduced (useSaveReportField, ReportFieldInlineInput, CONST.REPORT_FIELDS_PER_ROW, CONST.REPORT_FIELD_LIST_SEARCH_THRESHOLD) have no consumers outside the PR's own files, and no later PR on this checklist touched them. Only src/styles/index.ts and src/CONST/index.ts have since changed, so at worst the revert has trivial conflicts there.
Root Cause
Report fields deleted from a workspace deliberately survive on reports that already carry them, and the product's escape hatch was: open the field from the report → the editor page's three-dots menu → Delete → deleteReportField. #100735 converted those report field rows into inline TextInput/DatePicker/dropdown controls so that editing a value no longer navigates. That change removed the only entry point to the editor page for non-title fields without carrying the page's secondary action (Delete) over to the new inline UI, so a field removed from workspace settings is now permanently stuck on the report — the user can only blank its value, not remove it.
If a roll-forward is preferred over a revert
The other four blockers from this PR would still need individual fixes, but for this one specifically the targeted change is to give the inline field the action the editor page had: pass report into ReportFieldInlineInput, and for a field where reportField.deletable && reportField.fieldID !== CONST.REPORT_FIELD_TITLE_FIELD_ID, render a trashcan rightHandSideComponent / context menu item that runs the same confirm-modal-then-deleteReportField(report.reportID, reportField) flow currently in DynamicEditReportFieldPage.handleReportFieldDelete. That is new UI on a hot path with no design review, which is why REVERT is the recommendation.
💡 Suggested AI code review rule
This looks like a recurring, mechanically detectable pattern (App is steadily converting "row that navigates to an RHP page" into inline controls, and those pages routinely hold the feature's only Delete/secondary actions), so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:
Rule:UI-4 Preserve the destination page's actions when replacing a navigation row with an inline control
Condition: When a change removes the last Navigation.navigate(...) to a screen, flag it unless every action that screen exposed (three-dots menu items, delete, confirm flows) is reproduced in the replacement UI or still reachable elsewhere.
Why: Inline editing replaced the report field row, silently orphaning the editor page's three-dots Delete — the only way to remove a workspace-deleted field from a report — which blocked the 9.4.91-0 deploy (this issue).
Search pattern: for each route constant whose Navigation.navigate call is removed in the diff, run grep -rn "<ROUTE_CONSTANT>" src/ to confirm another entry point remains, and grep -n "threeDotsMenuItems\|menuItems.push\|showConfirmModal" <destination page> to list the actions that must be preserved.
The full rule file, with the ❌/✅ code inline in App's app-coding-standards format, would live in Expensify/App under .claude/skills/app-coding-standards/rules/. If it's worth adding, a maintainer can open it there as a draft PR.
Activity
applause-bot commentedon Sep 21, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/15a0e009c5f4cdab26b7d3cd4138d54a445ab595619913fd7dc45da4c3d5f413
melvin-bot commentedon Sep 21, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #100735
github-actions commentedon Sep 21, 2026
👋 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:
melvin-bot commentedon Sep 21, 2026
@Gonals @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #100735
melvin-bot commentedon Sep 21, 2026
💬 A slack conversation has been started in #expensify-open-source
MelvinBot commentedon Sep 21, 2026
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: Show up to three report fields per row and edit them inline (
Expensify/App#100735) by @MelvinBot (High confidence)Related Issues: Android - Expense - Report field value jumps when navigating from one report to another, Android - Expense - List dopdown auto closes after focusing on text field and opening list, Android - Expense - Report auto scrolls to bottom after opening report field, Expense - Cursor appears briefly on list report field after clicking on it — all five open deploy blockers on this checklist point at the same PR.
Recommendation: REVERT
PR #100735 replaced the report field rows (which navigated to the report field editor page) with inline inputs, and the editor page's three-dots Delete menu was the only UI that can remove a report field from a report — so the deletion path is now unreachable. Four sibling deploy blockers come from the same PR, so reverting it clears all five at once, and nothing merged after it depends on the code it added.
Assigned: @Gonals and @daledah (approving reviewers of #100735) are already assigned; the PR author is the
MelvinBotautomation account.Labels: No changes.
DeployBlockerCashstays (App-side regression, fix is inExpensify/App);DeployBlockerwas not present, so nothing to remove.📋 Detailed Analysis
Evidence
getAvailableReportFieldsinReportUtils.ts:4964-4966— "Get the report fields that are attached to a report. These will persist even if a field is deleted from the policy." So the row keeps rendering and the user needs an explicit way to remove it.deleteReportFieldis the three-dots menu on the report field editor page:DynamicEditReportFieldPage.tsx:136-147(deleteReportFieldis invoked at line 112; the only other call site insrc/is the action definition itself).MoneyRequestViewReportFields.tsx:57-86, with the navigation at line 74.MoneyReportView.tsxhad the same row and the same navigation for one-expense reports.MoneyRequestViewReportFields.tsx:67-96andMoneyReportView.tsx:169, which now delegate to the newReportFieldInlineInput.tsx(no delete affordance anywhere in that component).Verification
src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx,src/components/ReportActionItem/MoneyReportView.tsx,src/components/MoneyRequestReportView/ReportFieldInlineInput.tsx(new).productionandstagingare the ones this PR added or rewrote).DYNAMIC_ROUTES.EDIT_REPORT_FIELDinsrc/are for the title field (AvatarWithDisplayName.tsx:240andDynamicReportDetailsPage.tsx:1011), and the title field is explicitly excluded from the delete menu — so no non-title field can reach Delete any more.useSaveReportField,ReportFieldInlineInput,CONST.REPORT_FIELDS_PER_ROW,CONST.REPORT_FIELD_LIST_SEARCH_THRESHOLD) have no consumers outside the PR's own files, and no later PR on this checklist touched them. Onlysrc/styles/index.tsandsrc/CONST/index.tshave since changed, so at worst the revert has trivial conflicts there.Root Cause
Report fields deleted from a workspace deliberately survive on reports that already carry them, and the product's escape hatch was: open the field from the report → the editor page's three-dots menu → Delete →
deleteReportField. #100735 converted those report field rows into inlineTextInput/DatePicker/dropdown controls so that editing a value no longer navigates. That change removed the only entry point to the editor page for non-title fields without carrying the page's secondary action (Delete) over to the new inline UI, so a field removed from workspace settings is now permanently stuck on the report — the user can only blank its value, not remove it.If a roll-forward is preferred over a revert
The other four blockers from this PR would still need individual fixes, but for this one specifically the targeted change is to give the inline field the action the editor page had: pass
reportintoReportFieldInlineInput, and for a field wherereportField.deletable && reportField.fieldID !== CONST.REPORT_FIELD_TITLE_FIELD_ID, render a trashcanrightHandSideComponent/ context menu item that runs the same confirm-modal-then-deleteReportField(report.reportID, reportField)flow currently inDynamicEditReportFieldPage.handleReportFieldDelete. That is new UI on a hot path with no design review, which is why REVERT is the recommendation.💡 Suggested AI code review rule
This looks like a recurring, mechanically detectable pattern (App is steadily converting "row that navigates to an RHP page" into inline controls, and those pages routinely hold the feature's only Delete/secondary actions), so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for
Expensify/App:UI-4Preserve the destination page's actions when replacing a navigation row with an inline controlNavigation.navigate(...)to a screen, flag it unless every action that screen exposed (three-dots menu items, delete, confirm flows) is reproduced in the replacement UI or still reachable elsewhere.Navigation.navigatecall is removed in the diff, rungrep -rn "<ROUTE_CONSTANT>" src/to confirm another entry point remains, andgrep -n "threeDotsMenuItems\|menuItems.push\|showConfirmModal" <destination page>to list the actions that must be preserved.MoneyRequestViewReportFields.tsx:67-96on staging — inline input with no path to the page's Delete atDynamicEditReportFieldPage.tsx:136-147MoneyRequestViewReportFields.tsx:57-86on productionThe full rule file, with the ❌/✅ code inline in App's
app-coding-standardsformat, would live inExpensify/Appunder.claude/skills/app-coding-standards/rules/. If it's worth adding, a maintainer can open it there as a draft PR.melvin-bot commentedon Sep 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
Gonals commentedon Sep 22, 2026
PR Reverted
IuliiaHerets commentedon Sep 22, 2026
Chrome / 9.4.91-1
Passed
bandicam.2026-09-22.13-35-53-641.mp4