Rules - Require fields does not fill with the existing settings

[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: Exploratory - Significant User Experience Deterioration
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
4. Click on + Rule → Require fields → open category picker
5. Select a category that has an existing rule
6. Verify that the form fills with the existing settings
7. Select a category that doesn't have an existing rule
8. Verify that the form does not reset the settings of the previous category
9. Select another category that has an existing rule
10. Verify that the form does not fill with the existing settings

Expected Result:

The required fields are filled with the existing settings or reset if the category doesn't have an existing rule.

Actual Result:

The required fields do not fill with the existing settings, or the settings of a previous category are not cleared.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7198890_1783107948912.Create_dedup.mp4

View all open jobs on GitHub

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

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/7cfc5e9ac159b675c146ce23e61c063917085a7c83171907cf9bd8471d113499

[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 @rlinoz (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

Please re-state the problem that we are trying to solve in this issue.

In the Require fields rule creation flow (rulesRevamp beta), changing the selected category in the picker doesn't re-sync the form's toggle state. Only the first category you pick works — after that, picking a category with an existing rule won't pre-fill its settings, and picking a category with no rule won't reset the previous category's toggles.

What is the root cause of that problem?

When you save a category selection, onSave spreads the previous form draft (carrying the prior category's explicit toggle booleans) and passes it to getEffectiveRequireFieldsRuleForm:

const draftForm = { ...form, [INPUT_IDS.CATEGORY]: value };
updateDraftRequireFieldsRule(selectedCategory ? getEffectiveRequireFieldsRuleForm(selectedCategory, draftForm) : draftForm);

That helper resolves each field as form[field] ?? categoryForm[field] ?? false — so an explicit true/false already in the draft always wins over the newly-selected category's real settings. The ?? categoryForm fallback is only reached when the form value is undefined.

• First pick works because the draft is initialized to {} (no explicit booleans), so the ?? categoryForm branch runs.
• Every later pick breaks because the draft now holds explicit booleans from the previous selection, so the new category's settings are never read (no pre-fill) and can't be cleared (no reset). updateDraftRequireFieldsRule uses Onyx.merge, which also can't clear stale keys.

Data flow

1. Mount → draft = {}.
2. Pick category A (has rule) → form values undefined → falls through to A's settings. ✅ Works.
3. Draft now holds explicit toggles (e.g. requireDescription: true).
4. Pick category B (no rule) → form.requireDescription = true wins over B's false → toggles not reset. ❌
5. Pick category C (different rule) → stale booleans still win → C's settings not loaded. ❌

The checkboxes render from this same effectiveForm in RequireFieldsRulePageBase.tsx, so they display the stale state.

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

On category change, don't carry over the previous category's toggles — seed the draft from the newly-selected category's own settings. In onSave (RequireFieldsRuleCategoryPageBase.tsx:49-57):

const onSave = (value?: string) => {
    const selectedCategory = value ? policyCategories?.[value] : undefined;
    setDraftRequireFieldsRule({
        [INPUT_IDS.CATEGORY]: value,
        ...getRequireFieldsFormFromCategory(selectedCategory),
    });
};

getRequireFieldsFormFromCategory is already exported from RequireFieldsRulesUtils.ts and returns explicit booleans (all false when the category has no rule), which both pre-fills existing settings and resets stale toggles on every change. Using setDraftRequireFieldsRule (replace) rather than updateDraftRequireFieldsRule (Onyx.merge) also avoids stale keys.

Note: the form[field] ?? categoryForm[field] precedence in getEffectiveRequireFieldsRuleForm is intentional (represents "user hasn't touched this field → fall back to category"), so the fix belongs in how the draft is populated on category change, not in flipping that precedence.

What alternative solutions did you explore?

Flipping the ?? precedence to favor categoryForm was considered but rejected — it would break the intended "unset falls back to category" semantics used elsewhere (e.g. the checkbox render and saveRequireFieldsRule).

---

Confidence: High — code evidence traces the full input → bug → symptom chain, and it cleanly explains why only the first selection works.

Introduced by #94696.

---

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