FE-614 - Quick filter every search attribute value in the configurable tables

[rossedfort]

Description & motivation 💭

Only Keyword and Text cells offered a quick filter button, so a column like
StartTime, HistoryLength or TemporalChangeVersion could be read in the table
but not filtered from it. Every search attribute value in the configurable tables
can now seed a filter from the cell it is displayed in.

Clicking a cell's filter button opens a popover anchored to that cell, showing the
operators valid for the attribute's type with the cell's own value prefilled.
Nothing is applied until Apply (or Enter). The exception is a status column, which
still applies = in a single click: a status filter renders as the multi-select
chip rather than the operator form, and isTextFilter refuses status filters
outright, so the editor would otherwise fall through to a generic equals select.
That is the whole rule — requiresOperatorChoice asks whether the attribute is a
status, not what its default operator happens to be.

The popover reuses the filter bar's own form rather than reimplementing it. The
per-type operator toggles, date and time pickers, chip input and timezone handling
lived inside dropdown-filter-chip.svelte; they move to filter-editor.svelte,
which the chip and the cell popover both render. Input ids are namespaced by the
caller, since a chip and a cell popover can now be open at the same time.

The rest is removing near-duplicate implementations. Workflows, activities and
Nexus operations each had their own filterable-table-cell.svelte and each table's
body cell repeated the same derivation — label to attribute, attribute to type, row
to value, value to filter. Those collapse into:

• $lib/utilities/query/quick-filter.ts — the pure logic. Choosing the operator a
  popover opens on, coercing a cell value into something the query grammar accepts,
  and toggling a filter. Values arrive in whatever shape the API returned, so a
  datetime may be an ISO string, an epoch number, a Date or a protobuf
  Timestamp; normalizing is per-type rather than a String() call. A value that
  cannot be filtered on returns null, which is how a cell decides to render no
  button.
• quick-filter-table.ts and quick-filter-cell.svelte — one resolver and one
  cell. A table supplies a column config and a value getter and needs nothing else.
• A column-search-attributes.ts per table, mapping a column label to its search
  attribute and to the value to filter by.

ExecutionDuration is filterable, which needs care: it is typed Int but carries a
duration, and the displayed text is not reusable as a value. formatDistanceAbbreviated
(workflows, Nexus) delimits units with a space, while formatDurationAbbreviated
(activities) falls back to ', ' — stripping spaces from the latter yields 5m,10s,
which is not a duration. The value is built from the row's own data instead, truncating
rather than rounding so a >= filter on a row's duration still matches that row.

Filters are built on click rather than during render, since constructing one eagerly
per cell would mint a filter id for every row that is never used. Applying replaces
any existing filter on the same attribute rather than appending, so clicking down a
column moves the filter instead of accumulating contradictory clauses, and a
multi-status OR group collapses to the status that was clicked.

The buttons themselves no longer cost layout. Every filterable and copyable cell
previously reserved 64px of right padding for buttons that only appear on hover —
328px of a 1598px workflows table, about a fifth of it, for something invisible until
you hover. They are absolutely positioned over the right edge of their own cell, so
no column reserves width and it stays obvious which value they act on, at the cost of
covering the tail of a long value.

Screenshots (if applicable) 📸

Design Considerations 🎨

The operator a popover opens on is still type-derived — >= for datetimes, in for
keyword lists, >= for measures like HistoryLength, HistorySizeBytes,
StateTransitionCount and ExecutionDuration, = otherwise. Since the user now
confirms before anything is applied, that is a starting point rather than a guess the
table makes on their behalf.

Two things worth a look in review:

• A Datetime popover opens in absolute mode and keeps the cell's exact timestamp
  unless the pickers are touched. The pickers only carry seconds, so recomputing from
  them would round …01.726484047Z to …01.000Z.
• The workers table has the quick filter but not the popover. Its cell keeps a
  separate implementation for the SDK column, which applies SdkName and SdkVersion
  as one click. Its StartTime column is therefore the one place a Datetime still
  filters in one click, with >=.

Testing 🧪

How was this tested 👻

• Manual testing
• E2E tests added
• Unit tests added

Unit tests cover quick-filter.ts (operator choice, value coercion per attribute
type, toggle and active state, and a round trip from filter to query string and back
for every type), the duration conversion, quick-filter-table.ts, and the workflows
column mapping. Integration tests cover the popover end to end in
workflows-search-attribute-filter.desktop.spec.ts: a column asking for an operator
and applying nothing until confirmed, applying with a chosen operator, Status
filtering in one click, Enter applying, and that no column reserves width for the
buttons.

Steps for others to test: 🚶🏽‍♂️🚶🏽‍♀️

1. Open the workflows list on a namespace with a few hundred executions.
2. Add columns of varied types — Start, History Length, Execution Duration,
   Change Version, a custom bool or int search attribute.
3. Hover a cell and click the filter button. A popover should open against that cell
   with the value prefilled and an operator preselected, and nothing should be
   filtered yet.
4. Apply with the button and with Enter. Both should add one clause.
5. Change the operator before applying — a Start cell with Before should yield
   <= on the raw timestamp.
6. Hover a Status cell and click. It should filter in one click with no popover,
   and clicking again should clear it.
7. Click the same column on a different row — the clause should move rather than a
   second one being added.
8. Confirm Parent Namespace shows no filter button, and that no column is padded
   for the buttons when nothing is hovered.
9. Repeat on the activities, Nexus operations and workers tables.

Checklists

Draft Checklist

• Manual pass over all four tables
• Screenshots
• Check the popover against the first and last rows, where it flips to stay on screen

Merge Checklist

• Rebased onto main after FE-734 - Add resizable columns to the configurable tables #3925 merged
• main merged in, including Add a NOT IN operator for KeywordList search attributes #3961's not in operator

Issue(s) closed

Closes FE-614

Docs

Any docs updates needed?

None.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
holocene	Ready	Preview	Oct 7, 2026 7:18pm UTC