Skip to content

Expense - No option to remove report field from report after deleting from workspace settings #101805

Closed

Description

@applause-bot

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.


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.
  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create an expense.
  4. Go to workspace settings > Report fields.
  5. Click on the report field and delete it.
  6. Go back to workspace chat.
  7. 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.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7265677_1790019362746.3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7265677

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Sep 21, 2026
  2. applause-bot commented on Sep 21, 2026

    @applause-bot
    Author

    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

  3. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    You have been assigned to this deploy blocker because you recently merged this PR: #100735

  4. github-actions commented on Sep 21, 2026

    @github-actions
    Contributor

    👋 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.
  5. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    @Gonals @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #100735

  6. melvin-bot commented on Sep 21, 2026

    @melvin-bot

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

  7. MelvinBot commented on Sep 21, 2026

    @MelvinBot
    Contributor

    🔍 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 MelvinBot automation account.
    Labels: No changes. DeployBlockerCash stays (App-side regression, fix is in Expensify/App); DeployBlocker was not present, so nothing to remove.

    📋 Detailed Analysis

    Evidence

    Verification

    • Affected files: src/components/MoneyRequestReportView/MoneyRequestViewReportFields.tsx, src/components/ReportActionItem/MoneyReportView.tsx, src/components/MoneyRequestReportView/ReportFieldInlineInput.tsx (new).
    • 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.
    • Offending code (❌): MoneyRequestViewReportFields.tsx:67-96 on staging — inline input with no path to the page's Delete at DynamicEditReportFieldPage.tsx:136-147
    • Fix (✅): the row that kept the entry point, MoneyRequestViewReportFields.tsx:57-86 on production

    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.

  8. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    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.

  9. Gonals commented on Sep 22, 2026

    @Gonals
    Contributor

    PR Reverted

  10. IuliiaHerets commented on Sep 22, 2026

    @IuliiaHerets

    Chrome / 9.4.91-1
    Passed

    bandicam.2026-09-22.13-35-53-641.mp4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugSomething is broken. Auto assigns a BugZero manager.EngineeringReviewingHas a PR in review

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions