Rules - Missing "Don't require Description, don't require Attendees" at "Rules" column

[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.53-8
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97726
Email or phone of affected tester (no customers): applausetester+1221dv@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 11
App Component: Workspace Settings

Action Performed:

Precondition:Log in with Expensifail account; Enable Rules., Enable "Attendee tracking";

1. Open Expensify app
2. Go to workspace settings > Rules > Field requirements
3. Click Create field requirement rule. (upgrade the workspace if prompted)
4. Select a category
5. Select "Don't require" for Description and Attendee
6. Select Don't require for Receipt and Itemized receipt
7. Click Save rule
8. Open the created rule

Expected Result:

The text at "Rules" column should be "Don't require description, don't require attendee, don't require receipt, don't require itemized receipt"

Actual Result:

The text at "Rules" column show "Don't require receipt, don't require itemized receipt" and no "Don't require description, Don't require attendee" available.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7233501_1786703748393.MicrosoftTeams-video__7_.1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @Krishna2323

[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/4ababb45775fefaf1960db5304a714758c611022d6f4bdc6730767975a40420d

[melvin-bot]

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

[melvin-bot]

@JS00001 @situchan you have been assigned to this deploy blocker because you reviewed the offending PR: #97726

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

[melvin-bot]

@Krishna2323 you have been assigned to this deploy blocker because you authored the offending PR: #97726

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (the Require Fields Rules feature and any fix live entirely in Expensify/App)
Causing PR: #97726 is the melvin auto-assigned suspect, but investigation rules it out as the root cause (Low confidence it caused this symptom). The true cause is a pre-existing design/data-model limitation described below.
Related Issues: none identified

Recommendation: DEMOTE

This is a pre-existing, cosmetic gap in the Rules-column summary text (it reproduces on production, so it is not a regression introduced by this staging deploy), and reverting the auto-assigned PR #97726 would not fix it. It should not block the deploy; the underlying gap needs a product/data-model decision, not a revert.

Assigned: no assignee change — the auto-assigned PR #97726 is not the causing PR, so I am not adding contributors on its basis.
Labels: No changes. Keeping DeployBlockerCash pending a BugZero/product call on demotion (conservative: frontend feature, label was auto-applied). Do not revert #97726.

📋 Detailed Analysis

Where the "Rules" column text is built

The summary string in the Rules column is produced by, in order:

• createRequireFieldsTableItem → builds ruleDescription at RequireFieldsRulesUtils.ts#L665-L666
• getRequireFieldsRuleDescriptionsForCategory at RequireFieldsRulesUtils.ts#L552-L640
• formatRequireFieldsRuleDescriptions at RequireFieldsRulesUtils.ts#L540-L550

Root Cause

getRequireFieldsRuleDescriptionsForCategory only appends a clause when a field is actually required (isDescriptionRequiredForCategory, isAttendeesRequiredForCategory) or when a receipt field is waived (a distinct sentinel value DISABLED_MAX_EXPENSE_VALUE). There is no code path — and no translation key — that emits "Don't require description" or "Don't require attendee". Only doNotRequireReceipt / doNotRequireItemizedReceipt exist (en.ts#L7997-L7998).

The reason is the data model: Description and Attendees are stored as booleans (areCommentsRequired, areAttendeesRequired). Selecting "Don't require" simply means the flag is false — which is identical to the default "no rule" state and is not persistable as a distinct, displayable clause. This is even stated in the code comment at RequireFieldsRulesUtils.ts#L844-L851 and in the validation logic at #L530-L534: "Description/attendees 'Don't require' only clears a required flag and cannot create a waive rule."

In the exact repro, saveRequireFieldsRule confirms this: for Description/Attendees the effective value (DO_NOT_REQUIRE) equals the initial default, so the !== guards at #L368 and #L379 are false and nothing is persisted for those two fields. Only the Receipt/Itemized-receipt waives persist (via the sentinel), so only those two clauses appear in the summary — exactly matching the reported ACTUAL result.

Why PR #97726 is not the cause

PR #97726 ("Persist require fields tooltip dismissal and keep a direction always selected") changed only:

• getRequireFieldsDisplayedSetting + new canClearRequireFieldsField — makes the boolean-backed toggles show "Don't require" pre-selected instead of blank.
• Product-training tooltip dismissal persistence.
• Reordered the Attendees row above Receipt on the rule page.

It did not touch getRequireFieldsRuleDescriptionsForCategory, formatRequireFieldsRuleDescriptions, or saveRequireFieldsRule. The summary builder and the boolean data model both predate the PR, and the doNotRequireDescription/Attendee keys never existed. The one indirect link is that #97726 now pre-selects "Don't require" on those toggles, which makes a user expect the summary to echo the selection — but the missing-clause behavior itself is pre-existing and reverting #97726 would not add the clauses.

Verification

• Affected file: src/libs/RequireFieldsRulesUtils.ts (summary builder), src/languages/en.ts (missing translation keys).
• gh pr diff 97726 confirms the summary/save functions are unchanged by the PR.
• Reproducible on staging and production (per the report) → consistent with pre-existing feature behavior, not a fresh deploy regression.

Suggested resolution if pursued (frontend, follow-up — not a deploy blocker)

A real fix is a product/data-model decision, not a revert: to show "Don't require description/attendee" you would need to (a) add doNotRequireDescription/doNotRequireAttendee strings and emit them in getRequireFieldsRuleDescriptionsForCategory, and (b) resolve the ambiguity that areCommentsRequired: false is indistinguishable from "no rule" (otherwise every rule row would falsely display "Don't require description"). That warrants a scoped follow-up issue rather than blocking this deploy.