[Due for payment 2026-08-05] [$250] New Feature: Add Enabled/Disabled filtering for Multi-layer Tags

[m-natarajan]

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.44-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @Liz-Canary
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Workspace Settings.
2. Open Tags settings.
3. Create or view multiple tags in different states (Enabled and Disabled).
4. Attempt to sort or filter tags by their Enabled/Disabled status.
5. Observe the available options.

Expected Result:

A filter option (e.g., Enabled | Disabled) should be available at the top of the Multi-layer Tags table.
Users should be able to filter the list to display only enabled or disabled tags.

Actual Result:

No option is available to filter or sort Multi-layer Tags by Enabled or Disabled status.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3269.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080645997025391179
• Upwork Job ID: 2080645997025391179
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dannymcclain (NewFeature)

[MelvinBot]

Issue Analysis

This is a feature request, not a bug — the Expected/Actual sections read as swapped, but the title makes the intent clear: add an Enabled/Disabled status filter to the Multi-layer Tags view. Today no tags table has a status filter (neither single-level nor multi-layer); the "enabled" column is only sortable, and for dependent tags it isn't shown at all.

Where it lives today: The multi-layer per-list view is rendered by WorkspaceViewTagsTable, hosted by DynamicWorkspaceViewTagsPage. Its <Table.FilterBar> is a plain text search only — it passes no filters/isItemInFilter props to the shared <Table>, so there's no status dropdown.

Recommended approach: The shared <Table> already supports a filter dropdown via filters (FilterConfig) + isItemInFilter. Add a single-select filter (All / Enabled / Disabled) to WorkspaceViewTagsTable, copying the working pattern in WorkspaceMembersTable. Each tag row already carries an enabled: boolean, so no upstream data changes are needed.

⚠️ Design decision needed first: For dependent multi-layer tags the enabled column is intentionally hidden (shouldShowEnabledColumn = !hasDependentTags). Product/Design should confirm whether the filter applies to dependent-tag lists (where enable/disable state isn't currently surfaced) or only to non-dependent multi-level lists. It's already routed to the Design team — this scope call should be settled before implementation.

Investigation details & code references

• Single-level table: WorkspaceTagsTable/index.tsx:216 — enabled column is sortable (sortable: true) but FilterBar is text-search only; no filters prop.
• Multi-layer table: WorkspaceViewTagsTable/index.tsx — shouldShowEnabledColumn = !hasDependentTags; renders <Table> with only <Table.FilterBar>, no filters/isItemInFilter.
• Shared filter infra: Table.tsx, src/components/Table/TableFilterBar/, src/components/Table/middlewares/filtering.ts. Filter types live at CONST.TABLES.FILTER_TYPE (SINGLE_SELECT / MULTI_SELECT).
• Reference implementations already using this pattern: WorkspaceMembersTable, DomainMembersTable, WorkspaceCompanyCardsTable.

Data flow: WorkspaceTagsPage computes isMultiLevelTags/hasDependentTags and renders the list-of-lists → drilling in navigates to DynamicWorkspaceViewTagsPage → renders individual tag values via WorkspaceViewTagsTable. The issue's "top of the Multi-layer Tags table" phrasing points at WorkspaceViewTagsTable.

Related issues (not duplicates): #96390 (display tag GL codes), #94005 and #93731 (dependent-tag behaviors) — all touch the same tags surface but none add a status filter.

---

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 13:31:48 UTC.

Proposal

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

When viewing a multi-layer (multi-level) tag list under Workspace Settings → Tags, there is no way to filter the tags table by their Enabled / Disabled status. On large tag lists an admin has to scroll the entire table to find disabled (or enabled) tags.

(Minor: the Expected and Actual results in the issue body look transposed — Expected describes today's behavior and Actual describes the desired one. Worth correcting so it doesn't confuse QA later.)

What is the root cause of that problem?

This is a New Feature — the capability was simply never added.

Our shared Table component already supports status-style filtering out of the box: pass a filters config plus an isItemInFilter callback and it renders a filter trigger inside the FilterBar and applies the predicate. Members and Company Cards already use exactly this pattern (e.g. Company Cards' Assigned/Unassigned filter):

• App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

  Lines 266 to 297 in 1375738

  	const isItemInFilter: IsItemInFilterCallback<WorkspaceCompanyCardTableItemData> = (item, filterValues) => {
  	if (!filterValues || filterValues.length === 0) {
  	return true;
  	}
  	if (filterValues.includes('all')) {
  	return true;
  	}
  	if (filterValues.includes('assigned') && item.isAssigned) {
  	return true;
  	}
  	if (filterValues.includes('unassigned') && !item.isAssigned) {
  	return true;
  	}
  	return false;
  	};
  	const filterConfig: FilterConfig = {
  	status: {
  	filterType: CONST.TABLES.FILTER_TYPE.SINGLE_SELECT,
  	label: translate('common.status'),
  	options: [
  	{
  	label: translate('workspace.moreFeatures.companyCards.assignedCards'),
  	value: 'assigned',
  	},
  	{
  	label: translate('workspace.moreFeatures.companyCards.unassignedCards'),
  	value: 'unassigned',
  	},
  	],
  	},
  	};

• App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

  Lines 347 to 352 in 1375738

  	filters={filterConfig}
  	renderItem={renderItem}
  	keyExtractor={keyExtractor}
  	compareItems={compareItems}
  	isItemInSearch={isItemInSearch}
  	isItemInFilter={isItemInFilter}

The multi-layer tags table (WorkspaceViewTagsTable) renders <Table.FilterBar> for search only — it never passes a filters config or isItemInFilter, so no status filter appears even though each row already carries an enabled boolean:

• App/src/components/Tables/WorkspaceViewTagsTable/index.tsx

  Lines 92 to 112 in 1375738

  	return (
  	<Table
  	data={tags}
  	columns={columns}
  	selectionEnabled={selectionEnabled}
  	shouldEnableSelectionInNarrowPaneModal
  	selectedKeys={selectedKeys}
  	initialSortColumn="name"
  	title={translate('workspace.common.tags')}
  	renderItem={renderItem}
  	compareItems={compareItems}
  	isItemInSearch={isItemInSearch}
  	keyExtractor={(item) => item.keyForList}
  	onRowSelectionChange={onRowSelectionChange}
  	>
  	<Table.FilterBar label={translate('workspace.tags.findTag')} />
  	<Table.NoResultsState />
  	<Table.Header />
  	<Table.Body />
  	</Table>
  	);

The enabled value per tag is already assembled upstream in the row data, so all the data we need is present:

• App/src/pages/workspace/tags/DynamicWorkspaceViewTagsPage.tsx

  Lines 150 to 197 in 1375738

  	const tagRows = useMemo<WorkspaceTagTableRowData[]>(() => {
  	const enabledTagsCount = getCountOfEnabledTagsOfList(currentPolicyTag?.tags);
  	return Object.values(currentPolicyTag?.tags ?? {}).reduce<WorkspaceTagTableRowData[]>((acc, tag) => {
  	const isDisabled = tag.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
  	if (!isOffline && isDisabled) {
  	return acc;
  	}
  	const isDisablingLastEnabledTag = isDisablingOrDeletingLastEnabledTag(currentPolicyTag, [tag], enabledTagsCount);
  	acc.push({
  	keyForList: hasDependentTags ? `${tag.name}-${tag.rules?.parentTagsFilter ?? ''}` : tag.name,
  	value: tag.name,
  	name: hasDependentTags ? tag.name : getCleanedTagName(tag.name),
  	enabled: tag.enabled,
  	disabled: isDisabled,
  	errors: tag.errors ?? undefined,
  	pendingAction: tag.pendingAction,
  	isLocked: !canWriteTags || isDisablingLastEnabledTag,
  	showEnabledSwitch: !hasDependentTags,
  	showRequiredSwitch: false,
  	action: () => navigateToTagSettings(tag),
  	onToggleEnabled: (enabled: boolean) => {
  	if (isDisablingLastEnabledTag) {
  	showConfirmModal({
  	title: translate('workspace.tags.cannotDeleteOrDisableAllTags.title'),
  	prompt: translate('workspace.tags.cannotDeleteOrDisableAllTags.description'),
  	confirmText: translate('common.buttonConfirm'),
  	shouldShowCancelButton: false,
  	});
  	return;
  	}
  	updateWorkspaceTagEnabled(enabled, tag.name);
  	},
  	onClose: () =>
  	clearPolicyTagErrors({
  	policyID,
  	tagName: tag.name,
  	tagListIndex: orderWeight,
  	policyTags,
  	}),
  	});
  	return acc;
  	}, []);
  	}, [canWriteTags, currentPolicyTag, hasDependentTags, isOffline, navigateToTagSettings, orderWeight, policyID, policyTags, showConfirmModal, translate, updateWorkspaceTagEnabled]);

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

Wire a status filterConfig and an isItemInFilter predicate into the multi-layer tags table, reusing the same middleware Members/Company Cards use, in WorkspaceViewTagsTable:

const isItemInFilter: IsItemInFilterCallback<WorkspaceTagTableRowData> = (item, filterValues) => {
    if (!filterValues || filterValues.length === 0 || filterValues.includes('all')) {
        return true;
    }
    if (filterValues.includes('enabled') && item.enabled) {
        return true;
    }
    if (filterValues.includes('disabled') && !item.enabled) {
        return true;
    }
    return false;
};

const filterConfig: FilterConfig = {
    status: {
        filterType: CONST.TABLES.FILTER_TYPE.SINGLE_SELECT,
        label: translate('common.status'),
        options: [
            {label: translate('common.enabled'), value: 'enabled'},
            {label: translate('common.disabled'), value: 'disabled'},
        ],
    },
};

Then pass them to the existing <Table>, gated on shouldShowEnabledColumn so we don't offer a status filter for dependent tags (which have no per-tag enabled toggle):

<Table
    // ...existing props
    filters={shouldShowEnabledColumn ? filterConfig : undefined}
    isItemInFilter={isItemInFilter}
>

FilterConfig and IsItemInFilterCallback are exported from @components/Table; add them to the existing type import and import CONST. No new UI is needed — the filter trigger and the selected-filter chip render automatically inside the FilterBar that's already there.

The same filterConfig / isItemInFilter pair should be added to WorkspaceTagsTable for single-level tags too (gated on !isMultiLevelTags so it only shows on the individual-tags view, not the tag-lists overview where every row is a list). WorkspaceCategoriesTable has the identical bare-FilterBar gap — worth confirming with the assignee whether this issue should cover categories as well, since the change there is one-for-one identical and keeps workspace-settings consistent. Since a design assignee is on this, the exact label copy ("Status" dropdown vs. two Enabled/Disabled options) is worth confirming before implementation.

What specific scenarios should we cover in automated tests to prevent reintroducing this in the future?

• With a mix of enabled and disabled tags in a list, selecting Enabled shows only enabled rows; selecting Disabled shows only disabled rows; clearing the filter shows all.
• The status filter composes with the existing search box (search + status both applied).
• For a dependent multi-level tag list (no enabled column), the status filter is not offered.

What alternative solutions did you explore? (Optional)

• Sort-by-enabled only — the enabled column is already sortable, which groups enabled/disabled together, but it doesn't hide the other set, so it doesn't satisfy "display only enabled/disabled." A filter is the right primitive.
• A custom segmented Enabled/Disabled toggle above the table — more discoverable for a two-value filter, but it introduces a second filtering paradigm in workspace settings and reinvents the Table filtering middleware already used by Members and Company Cards, which supplies the chips, clearing, and empty state for free.
• MULTI_SELECT filter type — a single-select with Enabled/Disabled options is simpler and matches the Company Cards status filter; multi-select of both is equivalent to "no filter."

[abbasifaizan70]

Proposal

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

On the Multi-level Tags table (Workspace Settings > Tags > a tag list), there is no way to filter the tags shown by their Enabled/Disabled status. The table only supports a free-text "Find tag" search, so admins with long tag lists can't isolate just the enabled (or just the disabled) tags.

What is the root cause of that problem?

WorkspaceViewTagsTable renders the shared Table component but only wires up text search (isItemInSearch) via Table.FilterBar. It never populates the filters / isItemInFilter props that Table already supports for exactly this kind of dropdown filtering:

App/src/components/Tables/WorkspaceViewTagsTable/index.tsx

Lines 92 to 113 in 04e1c66

	return (
	<Table
	data={tags}
	columns={columns}
	selectionEnabled={selectionEnabled}
	shouldEnableSelectionInNarrowPaneModal
	selectedKeys={selectedKeys}
	initialSortColumn="name"
	title={translate('workspace.common.tags')}
	renderItem={renderItem}
	compareItems={compareItems}
	isItemInSearch={isItemInSearch}
	keyExtractor={(item) => item.keyForList}
	onRowSelectionChange={onRowSelectionChange}
	>
	<Table.FilterBar label={translate('workspace.tags.findTag')} />
	<Table.NoResultsState />
	<Table.Header />
	<Table.Body />
	</Table>
	);
	}

Because no filters config is ever passed in, TableFilterBar's hasFiltersAvailable check stays false and the dropdown-filter trigger next to the search box simply never renders — only the "Find tag" text input shows up. This filtering capability is a first-class, already-built feature of the shared Table component (see the filters/isItemInFilter props documented and exemplified right in the component's own header comment):

App/src/components/Table/index.tsx

Lines 16 to 29 in 04e1c66

	*
	* @example Full Featured
	* ```tsx
	* <Table
	* data={items}
	* columns={columns}
	* renderItem={renderItem}
	* isItemInSearch={searchFn}
	* compareItems={compareFn}
	* filters={filterConfig}
	* isItemInFilter={filterFn}
	* >
	* <Table.FilterBar />
	* <Table.Header />

Another table already wires this exact mechanism up for a different dropdown filter (group membership), which confirms the intended pattern for adding a new filter to a Table-based list:

App/src/hooks/useDomainGroupFilter.ts

Lines 41 to 65 in 04e1c66

	const filterConfig: FilterConfig<DomainMembersTableFilterKey> | undefined = !shouldShowGroupFilter
	? undefined
	: {
	group: {
	label: translate('common.group'),
	filterType: CONST.TABLES.FILTER_TYPE.SINGLE_SELECT,
	options: (groups ?? []).map((group) => ({
	label: group.details.name ?? '',
	value: group.id,
	})),
	},
	};
	const isItemInFilter: IsItemInFilterCallback<DomainMemberRowData> | undefined = !shouldShowGroupFilter
	? undefined
	: (item, filterValues) => {
	const filterValue = filterValues.at(0);
	const matchedGroup = groups?.find((group) => group.id === filterValue);
	if (!matchedGroup) {
	return true;
	}
	return String(item.accountID) in matchedGroup.details.shared;
	};

So the "Enabled/Disabled" filter isn't broken — it was simply never plumbed through for the Multi-level Tags table, even though the row data (item.enabled, see WorkspaceTagTableRowData) and the underlying Table filtering middleware already exist.

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

Wire up the existing Table filtering feature in WorkspaceViewTagsTable for the enabled state, following the same pattern as useDomainGroupFilter/DomainMembersTable above. No new UI primitives are needed — Table.FilterBar (already rendered at line 107) will automatically show the dropdown trigger as soon as a non-empty filters config is passed to Table.

Original code:

App/src/components/Tables/WorkspaceViewTagsTable/index.tsx

Lines 92 to 113 in 04e1c66

	return (
	<Table
	data={tags}
	columns={columns}
	selectionEnabled={selectionEnabled}
	shouldEnableSelectionInNarrowPaneModal
	selectedKeys={selectedKeys}
	initialSortColumn="name"
	title={translate('workspace.common.tags')}
	renderItem={renderItem}
	compareItems={compareItems}
	isItemInSearch={isItemInSearch}
	keyExtractor={(item) => item.keyForList}
	onRowSelectionChange={onRowSelectionChange}
	>
	<Table.FilterBar label={translate('workspace.tags.findTag')} />
	<Table.NoResultsState />
	<Table.Header />
	<Table.Body />
	</Table>
	);
	}

In WorkspaceViewTagsTable/index.tsx:

• Add a filters config (only when shouldShowEnabledColumn is true — dependent tags don't expose an enabled state/column, so the filter shouldn't apply there either) with a single enabled filter key, CONST.TABLES.FILTER_TYPE.SINGLE_SELECT, and two options built from translate('common.enabled')/translate('common.disabled').
• Add an isItemInFilter callback that reads the active filter value and compares it against item.enabled, returning true (no filtering) when no value is selected.
• Pass both filters={filters} and isItemInFilter={isItemInFilter} to the <Table> element.

const filters: FilterConfig<'enabled'> | undefined = shouldShowEnabledColumn
    ? {
          enabled: {
              label: translate('common.status'),
              filterType: CONST.TABLES.FILTER_TYPE.SINGLE_SELECT,
              options: [
                  {label: translate('common.enabled'), value: 'true'},
                  {label: translate('common.disabled'), value: 'false'},
              ],
          },
      }
    : undefined;

const isItemInFilter: IsItemInFilterCallback<WorkspaceTagTableRowData> = (item, values) => {
    const value = values.at(0);
    return !value || String(item.enabled) === value;
};

<Table
    ...
    isItemInSearch={isItemInSearch}
    filters={filters}
    isItemInFilter={isItemInFilter}
    ...
>

This requires importing FilterConfig and IsItemInFilterCallback from @components/Table and CONST from @src/CONST (already the app-wide constants module used for CONST.TABLES.FILTER_TYPE). With this in place, admins get a Status dropdown next to the existing search bar to show only Enabled or only Disabled tags, using the exact same reusable filtering mechanism already proven out for the Domain Members table.

[mukhrr]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[lorretheboy]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mkhutornyi (External)