Rules - Crossed‑out rule after offline edit

[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.4.27-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94696
Email or phone of affected tester (no customers): applausetester+ag110626ec@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.5
App Component: Workspace Settings

Action Performed:

Prerequisites:

• Use a workspace with Rules enabled (More features → Rules).
• Enable rulesRevamp beta on the test account: Onyx.merge('betas', ['rulesRevamp'])
• Enable Attendee tracking
• Add a different Required fields rule for at least 2 categories

1. Navigate to https://staging.new.expensify.com/
2. Log in with any Expensifail account as a workspace admin
3. Go to workspace settings > Rules > Require fields tab
4. Go offline
5. Go to any rule details
6. Deselect Description and select Attendees
7. Click on Save rule

Expected Result:

The rule is displayed as a greyed-out row and allows editing.

Actual Result:

The rule is displayed as a deleted row (shown crossed‑out) and is locked against editing.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7198934_1783112062325.Crossed_out_rule.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @situchan

[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/e7a8f4127ce6865e93bd5a966517ed8e5d560b8a9c54af1a547c47bc31ef9de9

[melvin-bot]

@luacmartins recently merged #94696, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @mountiny (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[github-actions]

👋 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.

[MelvinBot]

Proposal

Root Cause: Editing a Require fields rule offline that removes one field while adding another makes the whole rule row render as deleted (strikethrough + locked) instead of a greyed‑out editable UPDATE row. Regressed by #94696.

The remove path sets a field‑level DELETE (while keeping the category‑level pendingAction correctly at UPDATE) in setPolicyCategoryDescriptionRequired (Category.ts:426-434). But when the table aggregates the row's pending action, getRequireFieldsPendingAction (RequireFieldsRulesUtils.ts:190-196) returns the first field whose action is delete‑or‑update. areCommentsRequired (the removed field, DELETE) is first in the list, so it wins over areAttendeesRequired (UPDATE):

return pendingActions.find((pendingAction) => isPendingDeleteOrUpdate(pendingAction)) ?? pendingActions.at(0);

The row then gets pendingAction: DELETE and disabled: true at RequireFieldsRulesUtils.ts:284-309, which the row renders as crossed‑out and non‑editable at WorkspaceRequireFieldsTableRow.tsx:36-43.

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

Fix the aggregation so a field‑level DELETE only collapses to a whole‑row DELETE when the rule is actually being fully removed (every pending field is DELETE). Otherwise it's an edit and should be UPDATE.

In getRequireFieldsPendingAction, when the collected pending actions contain a mix of DELETE and UPDATE, return UPDATE; return DELETE only when all pending fields are DELETE. This keeps a genuine full‑rule delete rendering as strikethrough/locked, while an edit that removes one field but keeps or adds another renders as a greyed‑out, editable UPDATE row.

Investigation details & data flow

1. Offline Save → handleSave → saveRequireFieldsRule (RequireFieldsRulePageBase.tsx:148-162).
2. Description off → setPolicyCategoryDescriptionRequired(..., false); Attendees on → setPolicyCategoryAttendeesRequired(..., true) (RequireFieldsRulesUtils.ts:107-125).
3. Onyx merges → category pendingFields = {areCommentsRequired: 'delete', areAttendeesRequired: 'update'}, category‑level pendingAction: 'update'.
4. getRequireFieldsPendingAction returns 'delete' (first delete‑or‑update field wins).
5. Row item gets pendingAction: 'delete', disabled: true → strikethrough + locked.

The action functions are correct — the category‑level pendingAction is UPDATE. The bug is purely in the row aggregation collapsing a per‑field DELETE into a whole‑rule delete. Sibling tables (Spend rules / Expense defaults) don't hit this because they read the category‑level pendingAction directly and their remove path never writes a field‑level DELETE (setPolicyCategoryReceiptsRequired, Category.ts:496-507).

Alternative considered: derive the row's delete state from whether the category will have no require‑fields rules left after the pending change (via categoryHasAnyRequireFieldsRule) rather than from the aggregated pending action. Equivalent outcome; the aggregation fix is more localized.

Confidence: High — fully code‑traceable offline/optimistic‑data logic; no production logs needed.

---

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