Filtering and search

The / filter: substring search, field:value restrictions, and how it composes with namespaces and owner scope.

Press / to filter the current table live. Filtering is a pure, client-side predicate over the rows already loaded, so it is instant and never hits the API. It composes with everything else: the namespace scope, the owner-scope toggles, and the view you are on all still apply, and the filter narrows what is left.

How the query works

The text you type is split on whitespace into terms, and the terms are ANDed together: a row is kept only if it matches every term. Each term is one of two things.

  • A bare substring matches against the row’s name and every rendered column. Typing gcp keeps any row where gcp appears anywhere.
  • A field:value term restricts the match to a single column. provider:gcp keeps only rows whose PROVIDER column contains gcp.

Because the terms are ANDed, you can stack restrictions:

provider:gcp status:stopped

keeps the rows that are both on GCP and stopped. Field names are the column titles, lowercased (status, provider, address, target, and so on).

To clear the filter and see the full table again, press / and then esc. Switching to another tab also clears it.

Tip

The same accessor feeds both the rendered cell and the filter, so a row always filters on exactly the text you see in its columns. There is no hidden field that matches differently from what is on screen.

The relations filter

The x key also sets a filter. On a config, binding or SSH key, x switches to the Workstations tab and keeps only the workstations that object applies to. The line above the table names the filter, for example users of base. Clear it the same way as a filter you typed.

On a workstation, x opens the Related view instead, a separate list of the configs, bindings and SSH keys tied to it. See Inspecting.