Move multi-level tag Required from the Tags table to Rules

[Krishna2323]

Explanation of Change

Fixed Issues

$ #95764
PROPOSAL:

Tests

Testing steps

Per-level Required — independent multi-level tags

1. On Control with rulesRevamp enabled, create two independent tag lists (e.g. State, Region), each with enabled tags.
2. Go to Rules → General → Require fields for all expenses.
3. Verify one toggle per tag list, labelled by its name, plus Category.
4. Enable State, leave Region off, and save.
5. Reopen and verify State is on, Region is off, and the General row lists the required fields correctly.

Single/dependent tags

6. With one tag list (e.g. Department), verify one Department toggle and matching General row description.
7. With dependent tag lists, verify one Tag toggle and Tag in the General row.

Disabled tag levels

8. Disable all tags in Region and verify its Required toggle is disabled while State remains interactive.
9. If Region is already required, verify its toggle remains interactive so it can be turned off.

Tags load without visiting Tags

10. After a fresh login/hard refresh, go directly to Rules → General → Require fields and verify per-level tag rows load correctly.

Required removed from Tags table (beta on)

11. Verify the Required column, row switches, bulk Require/Make optional actions, and detail-page toggle are gone.
12. Verify Delete selection still works.

Beta off

13. Disable rulesRevamp and verify all existing Required controls/actions return and work, including the warning when making the last required tag list optional.

• Verify that no errors appear in the JS console

Offline tests

• Same as tests

QA Steps

• Same as tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified there are no new alerts related to the canBeMissing param for useOnyx
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

android_hybrid.mp4

Android: mWeb Chrome

android_mWeb.mp4

iOS: Native

ios_hybrid.mp4

iOS: mWeb Safari

ios_mWeb.mp4

MacOS: Chrome / Safari

web_chrome.mp4

[melvin-bot]

@situchan Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[Krishna2323]

@MelvinBot review

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/components/Tables/WorkspaceTagsTable/index.tsx	69.81% <100.00%> (+0.58%)	⬆️
src/libs/actions/Policy/Category.ts	50.00% <100.00%> (-0.72%)	⬇️
.../RequireFieldsRules/FieldRequirementSettingRow.tsx	0.00% <0.00%> (ø)
...reFieldsRules/FieldRequirementsDirectionToggle.tsx	0.00% <0.00%> (ø)
...pendRules/SpendRuleRestrictionTypeToggleRevamp.tsx	0.00% <0.00%> (ø)
src/pages/workspace/tags/WorkspaceTagsPage.tsx	48.60% <66.66%> (-0.14%)	⬇️
src/libs/PolicyUtils.ts	77.67% <50.00%> (-0.02%)	⬇️
...es/workspace/tags/DynamicWorkspaceViewTagsPage.tsx	0.00% <0.00%> (ø)
...pace/rules/IndividualExpenseRulesSectionRevamp.tsx	2.08% <0.00%> (-0.27%)	⬇️
...c/pages/workspace/rules/RulesRequireFieldsPage.tsx	70.66% <65.07%> (+3.29%)	⬆️
... and 1 more
... and 207 files with indirect coverage changes

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 62ceef335c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[MelvinBot]

Reviewed the changes. The overall approach is clean — gating the old Required column/switches/bulk-actions behind rulesRevamp and moving per-level Required into the Rules page reads well, and the tests track the new behavior. Two things stood out: one likely bug, one behavior question.

🐛 Per-level toggles render stale (all-off) after a delayed tag load

This is exactly testing step 10 (fresh login / hard refresh → go straight to Rules → General → Require fields).

The sync effect is one-shot per policy.id, but tagRequiredByLevel is derived from policyTags, which loads asynchronously via openPolicyTagsPage — a plain API.read with no optimistic data (Tag.ts:71-82). On a hard refresh the policy object usually resolves before the tags arrive, and then:

1. The effect runs while initialTagRequiredByLevel is still {}, sets syncedPolicyIDRef.current = policy.id, and stores {}.
2. Tags land, initialTagRequiredByLevel recomputes to the real per-level values, the effect re-fires — but the syncedPolicyIDRef.current === policy.id guard now early-returns.
3. The real values never reach state, so every level renders OFF even when required (RulesRequireFieldsPage.tsx:285).

policy.isLoading only tracks the policy object, not the tags, so nothing re-syncs once the tags arrive (sync effect L84-L93). The tests don't catch it because setupPolicy seeds policyTags before render.

Suggested fix: sync tagRequiredByLevel in its own effect that re-applies when policyTags populates (or drop it from the policy.id-guarded effect), so it isn't committed before the tags exist.

❓ "Can't make all tag lists optional" guard is dropped for independent multi-level tags

On the old Tags table, toggling off the last required list is hard-blocked with the cannotMakeAllTagsOptional warning (WorkspaceTagsPage.tsx:302-305). The new per-level toggles have no equivalent — with rulesRevamp on, a user can turn every level optional and Save. Testing step 13 verifies that warning for beta-off, but there's no beta-on counterpart. Is dropping that protection intentional for the revamp, or should it be carried over to the per-level toggles?

---

Nothing else blocking from my read. Happy to implement either fix — reply with @MelvinBot implement ... if you'd like me to.

[github-actions]

🚧 JmillsExpensify has triggered a test Expensify/App build. You can view the workflow run here.

[JmillsExpensify]

Tested for a direct integration. Wouldn't these be locked on instead of locked off for this case? We are importing these two accounting lists as tags from NetSuite and they should both be required.

[Krishna2323]

Tested for a direct integration. Wouldn't these be locked on instead of locked off for this case? We are importing these two accounting lists as tags from NetSuite and they should both be required.

@JmillsExpensify could you please share the steps you followed? Did you use the Sage Intacct C+ Contributor+ account?

[trjExpensify]

Not sure on the steps, but it's a workspace connected to NetSuite I added him to owned by tom+integrationsmaster@trj.chat

1. tom+integrationsmaster@trj.chat created a workspace and connected to NetSuite
2. Imported departments as report fields
3. Imported classes and locations as tags
4. Invited jason@ to the workspace as an admin

I guess I'm not really following this screen, why would making a tag level required or not be locked? I understand the category one because we force you to minimally categorise expenses.

[Krishna2323]

Not sure on the steps, but it's a workspace connected to NetSuite I added him to owned by tom+integrationsmaster@trj.chat

1. tom+integrationsmaster@trj.chat created a workspace and connected to NetSuite
2. Imported departments as report fields
3. Imported classes and locations as tags
4. Invited jason@ to the workspace as an admin

I guess I'm not really following this screen, why would making a tag level required or not be locked? I understand the category one because we force you to minimally categorise expenses.

@MelvinBot review and also check if there are any behavioral changes.

[situchan]

Failure scenario is not working correctly.

Precondition: Simulate network failing requests

1. Multi-level independent tags, Department not Required.
2. Rules → Require fields → turn Department on → Save.
3. The row shows no error, the toggle stays on, and Onyx keeps required: true until something refetches the tag lists
   • Expected: toggle reverts to off with a dismissible red-brick-road error, as the tag list detail page still does.

Category works better but still has bug: toggle reverts to off but no RBR feedback

Screen.Recording.2026-08-14.at.5.28.05.PM.mov

[situchan]

Bug: A mixed require/unrequire save wipes the newly added violation

1. Multi-level independent tags, Department Required, Region not, both with some enabled tags.
2. Create an expense with no tags → it shows a Missing Department violation.
3. Go offline
4. Rules → Require fields: turn Region on first, then Department off → Save
5. The expense shows no tag violation at all until online. Online it self-corrects when the server pushes violations; offline it stays wrong until reconnect.
   • Expected: Missing Region.

Screen.Recording.2026-08-14.at.5.40.03.PM.mov

[situchan]

#97639 bug regressed

Screen.Recording.2026-08-14.at.5.47.07.PM.mov

1. Control workspace, beta on. More features → turn Tags off.
2. Connect an accounting integration that doesn't import tags
3. More features → the Tags toggle is now locked ("connection manages this").
4. Rules → Require fields → tap the locked Tag row → confirm.
5. Actual: enablePolicyTags(true) fires and Tags turns on.
   • Expected: the accounting modal with "Manage settings" routing to the Accounting page.

[situchan]

Was there a discussion for this?
In production, there's no way to enable multi-level tags when account connected

[Krishna2323]

We can enable/disable tags when account is connected, the tags need to be imported before we connect to account. See #98414 (comment)

Monosnap.screencast.2026-08-15.00-14-45.mp4

[situchan]

Both params are from the same object.
getLevelRequired(tagList) is strictly better and shortens every call site.

[Krishna2323]

threaded the tag list through isLastRequiredLevel and handleTagListRequiredToggle.

[Krishna2323]

• Tap Region row -> confirm the "Enable tags and require" modal.

• Tag is enabled and both Department and Region flip to Required <--- bug

  • Expected: Only Region flips

fixed

Monosnap.screencast.2026-08-14.23-50-40.mp4

All Required toggle on status saved automatically <--- bug? (I noticed that same happens on Category)
Expected: Even Region should revert back to not required

enablePolicyCategories sets requiresCategory to true so I kept the same behaviour for tag also.

3. The row shows no error, the toggle stays on, and Onyx keeps required: true until something refetches the tag lists

   • Expected: toggle reverts to off with a dismissible red-brick-road error, as the tag list detail page still does.

Category works better but still has bug: toggle reverts to off but no RBR feedback

Fixed, category has no RBR on staging also (leagcy).

Monosnap.screencast.2026-08-14.23-54-16.mp4

Bug: A mixed require/unrequire save wipes the newly added violation

Fixed:

Monosnap.screencast.2026-08-15.00-09-20.mp4

#97639 bug regressed

Fixed

Monosnap.screencast.2026-08-15.00-12-44.mp4

[Krishna2323]

Fixing Rules - Add Spend Rules - Restrict merchants options shifts upwards while changing language to Espanol and other languages here:

Monosnap.screencast.2026-08-16.23-05-13.mp4

[Krishna2323]

@situchan could you please prioritize this when you get a chance? Thanks!

[situchan]

Optimistic violations are still not working properly. Both category and tag

Screen.Recording.2026-08-17.at.8.06.52.PM.mov

[situchan]

Bug: Tag can be enabled but cannot be disabled back.
It says "your workspace settings require tags" but where to disable it other than this page?

Screen.Recording.2026-08-17.at.8.11.04.PM.mov

[Krishna2323]

Optimistic violations are still not working properly. Both category and tag

Fixed

[Krishna2323]

Bug: Tag can be enabled but cannot be disabled back. It says "your workspace settings require tags" but where to disable it other than this page?

Same reproducible on staging also:

Monosnap.screencast.2026-08-18.01-22-43.mp4

[situchan]

Bug: Tag can be enabled but cannot be disabled back. It says "your workspace settings require tags" but where to disable it other than this page?

Same reproducible on staging also:

Monosnap.screencast.2026-08-18.01-22-43.mp4

ok, looks like there's no way to set policy.requiresTag back to false once it's set to true, without disabling Tags feature and then enabling back.

[situchan]

There's still bug in optimistic violation but I reproduced this in production as well. So I think we can fix this separately, not blocking Rules feature.

1. Toggle "Members must categorize all expenses" on
2. Create expense without category
3. "Missing category" violation shows
4. Go offline
5. Toggle "Members must categorize all expenses" off
6. "Missing category" violation doesn't disappear until online <--- bug happening on production

Screen.Recording.2026-08-17.at.9.14.49.PM.mov

[MelvinBot]

Review

Overall this is a well-structured change — the hard part (recomputing violations once from the combined end state, and splitting a mixed require/optional save into one request per direction so the last write can't clobber the others) is handled carefully and the comments explain the "why" well. I traced the new action (setPolicyTagLevelsRequired), the pushTransactionViolationsOnyxData arg order, and the beta gating on the Tags table/detail pages — all consistent. One likely bug stands out:

🐛 A required level whose tags are all disabled can't be turned off

RulesRequireFieldsPage.tsx:320

isActive={getLevelRequired(tagList) && areLevelTagsEnabled}

For a level that is already Required but currently has all of its tags disabled (areLevelTagsEnabled === false):

• isActive evaluates to false, so the switch renders OFF.
• isLevelToggleDisabled = isTagFeatureDisabled || (!tagList.required && !areLevelTagsEnabled) is false (because tagList.required is true), so the row stays interactive — matching your testing step 9.
• But since the switch shows OFF, tapping it fires onToggle(true) → handleTagListRequiredToggle(true, …), which just re-sets the level to required. The user can never make it optional.

This directly contradicts testing step 9 ("If Region is already required, verify its toggle remains interactive so it can be turned off") — it's interactive but not actually turn-off-able.

The && areLevelTagsEnabled guard is only needed to keep a not-yet-required empty level from being switched on, and isLevelToggleDisabled already covers that case. Dropping it fixes the required case while leaving the disabled behavior intact:

isActive={getLevelRequired(tagList)}

Truth table after the suggested change

Level state	tags enabled?	isActive	disabled	Result
not required	no	false	true	can't turn on (correct)
not required	yes	false	false	can turn on
required	no	true	false	shows ON, can turn off ✅
required	yes	true	false	shows ON, can turn off

Minor / non-blocking

• IndividualExpenseRulesSectionRevamp.tsx fires openPolicyTagsPage(policyID) on every mount of the General tab to hydrate the subtitle's tag-list names. Correct, but worth confirming it doesn't cause a redundant fetch when the user is bouncing between tabs. Not a blocker.
• If category and a tag level both change in one save and one request fails while the other succeeds, violations can be momentarily out of sync until the next policy refresh (the single recompute lives only in the tag request). This is inherent to the two-request design and self-heals — just flagging it as a known edge.

I focused on a static code review (didn't set up a live Control workspace with rulesRevamp + independent multi-level tags). The empty-tags-key defensive fixes in PolicyUtils and the beta gating on the Tags table/detail/bulk-action paths all look correct.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ccfea93255

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[MelvinBot]

Beta on/off regression analysis

Beta OFF matches production ✅ (one ungated exception, noted below). I traced every one of the 12 changed files and confirmed each behavioral change is either rendered only inside revamp-only pages/components or guarded by an explicit !isRulesRevampEnabled condition that reproduces the old expression when the beta is off.

Beta ON has one real regression — the required-level toggle bug I flagged in the earlier review is still the main one.

Beta-OFF gating — how each change is neutralized

• RulesRequireFieldsPage.tsx:275 → shouldBeBlocked={!isRulesRevampEnabled}, so the whole page (per-level toggles, the isTagToggleDisabled/shouldShowTagLock changes, the two-request save) is unreachable beta-off, even via deeplink.
• IndividualExpenseRulesSectionRevamp.tsx only renders through PolicyRulesPage → returns PolicyRulesPageRevamp only when isRulesRevampEnabled (PolicyRulesPage.tsx:76).
• FieldRequirementSettingRow.tsx / FieldRequirementsDirectionToggle.tsx (the flexWrap/alignSelfStart style tweaks) render only via RequireFieldsRulePageBase, which is shouldBeBlocked={!isRulesRevampEnabled}.
• SpendRuleRestrictionTypeToggleRevamp.tsx renders only in revampFormContent (isRulesRevampEnabled ? revampFormContent : legacyFormContent).
• WorkspaceTagsTable/index.tsx, WorkspaceTagsPage.tsx, DynamicWorkspaceViewTagsPage.tsx → all new conditions are … && !isRulesRevampEnabled (and wrapperStyle={isRulesRevampEnabled ? … : undefined}), so beta-off evaluates to the exact prior expression.
• Category.setWorkspaceRequiresCategory and Tag.setPolicyRequiresTag gained trailing default params (shouldRecomputeViolations = true, extraPolicyUpdate = {}). Every non-revamp caller (WorkspaceTagsSettingsPage, DynamicWorkspaceCategoriesSettingsPage) still calls them with the original 2 args → identical behavior. setPolicyTagLevelsRequired is new and only called from the beta-blocked page.

⚠️ The one ungated change — safe, but worth a look

PolicyUtils.ts:2016 and :2023 changed Object.values(tagList.tags) → Object.values(tagList.tags ?? {}) in hasDependentTags/hasIndependentTags. These are shared utils that run regardless of beta. It's the only place where beta-off code differs. It only changes the case where a tag list arrives without a tags key (which the PR comment says does happen for empty lists) — old code would throw, new code treats it as empty. That's strictly a hardening, not a regression, but it does mean beta-off is not byte-for-byte the old behavior in that edge case. Worth confirming it isn't masking a real "should never be empty" invariant.

🐛 Regression when beta ON

Same issue as my earlier review, restating for completeness — a required level whose tags are all disabled renders the toggle OFF and can't be turned off:

RulesRequireFieldsPage.tsx:320 — isActive={getLevelRequired(tagList) && areLevelTagsEnabled}. The row stays interactive (correct), but because it shows OFF, tapping fires onToggle(true) and just re-requires it — the admin can never make it optional. Drop && areLevelTagsEnabled (the isLevelToggleDisabled gate already prevents turning on an empty level). Contradicts your own testing step 9.

Intentional behavior change to confirm (not a bug)

Beta-on, the tag Required control is no longer locked when connected to accounting (isTagToggleDisabled L63, shouldShowTagLock L163 both dropped isConnectedToAccounting), unlike the Category control which still locks. Your commit message says this is deliberate ("a connection owns the tag lists, not whether an expense must carry one") — just flagging it so a reviewer confirms Categories-locks-but-Tags-doesn't is the intended asymmetry.

_{This is a static gating/regression analysis of the diff — verifying "beta off == production" is fundamentally a code-path question, so I proved it from the gates rather than diffing two live builds.}