feat(data-table): add filter operator allowlists

[IzumiSy]

Motivation

DataTable.Filters currently decides the available conditions entirely from the filter type. That works for broad defaults, but it gives consumers no way to narrow the filter UI for a specific column.

This change adds a column-level allowlist so a table can expose only the conditions that make sense for that field, while keeping the existing collection control and persisted filter formats compatible.

Design Decision

Chosen approach

Add an optional operators property to Column.filter and treat it as a DataTable UI allowlist.

The configured order drives both the operator menu order and the default operator. The same override is also supported in inferColumns(..., { filter: { operators: [...] } }) so metadata-derived columns can use the feature without switching to manual filter config.

Compatibility boundary

The allowlist only affects the built-in DataTable filter UI. CollectionControl.addFilter(...), URL state, and saved filters still accept the broader backend operator set.

To avoid silently rewriting existing state, active filters whose operator is no longer in the configured allowlist are still preserved and rendered, but new operator choices come from the configured set.

Alternatives considered

A broader shared FilterConfig change would have mixed backend query semantics with DataTable-specific UI behavior. Keeping the allowlist at the DataTable column layer keeps the API smaller and avoids changing collection-wide contracts.

Summary

• add filter.operators to DataTable columns to narrow the built-in filter UI per column
• support the same operator override in inferColumns() metadata helpers
• update DataTable filter behavior, tests, docs, and add a changeset for the new API

[github-actions]

Code Metrics Report

	main (a3890d8)	#462 (ba9af90)	+/-
Coverage	90.0%	90.1%	+0.0%
Test Execution Time	2m2s	2m2s	0s

Details

  |                     | main (a3890d8) | #462 (ba9af90) |  +/-  |
  |---------------------|----------------|----------------|-------|
+ | Coverage            |          90.0% |          90.1% | +0.0% |
  |   Files             |            152 |            152 |     0 |
  |   Lines             |           5174 |           5201 |   +27 |
+ |   Covered           |           4661 |           4690 |   +29 |
  | Test Execution Time |           2m2s |           2m2s |    0s |

Code coverage of files in pull request scope (78.1% → 79.4%)

Files	Coverage	+/-	Status
packages/core/src/components/data-table/field-helpers.ts	100.0%	0.0%	modified
packages/core/src/components/data-table/toolbar.tsx	78.8%	+1.2%	modified

---

Reported by octocov

[IzumiSy]

/review

[github-actions]

✅ Code Review completed successfully!

[github-actions]

Generated by Code Review for issue #462 · 42.3 AIC · ⌖ 8.61 AIC · ⊞ 5.9K
_{Comment /review to run again}

[interacsean]

1 must-fix, plus docs. No issue is linked to this PR, so I reviewed against the PR's stated goals and platform-planning#1509 (which fixed the current per-type default operators). The four code comments below are largely one root cause — see the comment on getConfiguredFilterOperators.

The backwards compatibility offered to support saved URLs and bookmarks — where filter operators that are no longer offered by default still get applied — is a solid choice (pre-existing, and hardened here with isUiOperatorAllowedForType). Noting it and asking whether it can ever be deprecated. I suggest not: we can never force a user to stop using an old bookmark.

Everything else is mechanically clean: operator derivation stays confined to toolbar.tsx (grepped getAddFilterOperators, STRING_OPERATORS, DATE_OPERATORS, NUMERIC_TEMPORAL_OPERATORS, BOOLEAN_OPERATORS — no other consumer), the out-of-allowlist preservation path is consistent across all six editors and both surfaces, every Extract<OperatorForFilterType[T], …> narrowing resolves non-never, PanelValueEditor handles a single-operator between allowlist without malformed commits, the interface→type change on MetadataFieldOptions stays assignable from the un-parameterized form, and vite build emits declarations cleanly.