One component, used by every view. The URL is the filter state: shareable, back-button-correct, and the only place the panel reads it from.
A filter used to be applied as an ordinary Solr filter, with the facet over the same field computed inside it. So the moment you picked one virtual host, the host facet listed exactly one value: every other host had been filtered out of its own facet. The interface removed the options a multi-select needs — you could not see what else existed and you could not add a second value.
Measured against a real Solr node, with one content-type filter applied:
facet with no exclusion -> text/html 483 (one option, and no way back) facet with excludeTags -> text/html 483, application/pdf 2 (both, with honest counts) headline count in both -> 483, the fully filtered total
Each dimension’s filter carries a tag generated from the allowlisted field name — never from request text — and that dimension’s own facet is asked for with its own tag excluded and no other. So:
Figure 1 — one Solr round trip answers a whole sidebar, however many dimensions it has. Counts say which of the two populations they describe, because with exclusions in play it is easy to render a number that answers a different question than its label claims.
| Operator | Means | Offered on |
|---|---|---|
| Any of (default) | Match any of the selected values | every dimension |
| All of | Match all of them at once | multi-valued fields only — paths and signals |
| None of | Everything except the selected values | every dimension |
All of is withheld rather than shown-and-disabled on a single-valued field: “a and b” over one value per document is empty by construction, and a control whose only possible answer is zero results is worse than no control. A test in the repository reads the schema and fails if the interface and the schema disagree about which fields are multi-valued.
It is what finally expresses an absent field. The signed-in flag is written only when the measured site said something, so “not reported” is “none of true or false” — a real, selectable filter rather than a read-only number with an apology attached. The same applies to the planes dimension, where asking for sessions that have a transport plane means excluding beacon-only rather than selecting log-only.
?v=networks&range=7d &f[as_type_s][]=hosting&f[as_type_s][]=vpn&f[as_type_s][op]=none &f[paths_ss][]=/pricing&f[paths_ss][]=/docs&f[paths_ss][op]=all
One parameter family carries a dimension’s whole state: numeric keys are values, op is the operator, any other key is ignored. Identifiers and labels is the page that tells you what to put in those values.
- An absent operator means “any of”, and the default is never written out — so every URL bookmarked or shared before the operator existed behaves byte for byte as it did, and a shared link does not change shape for nothing.
- A field not on the plane’s allowlist is dropped in silence. Twenty values per dimension, 256 characters per value.
- A value that cannot be the field’s type — a non-number for a numeric field, anything but true or false for a boolean — is dropped at the boundary, so a hand-edited URL produces a filter nobody set rather than a Solr error.
- Changing any filter drops the page offset. Page four of the old result set is not a place to land.
The Opensolr request-log plane uses the same shape under a separate parameter family, because those field names exist on the platform’s analytics and none of Loghound’s own fields does.
Two controls, applied by one rule everywhere rather than on three dimensions and not the rest:
- An inline filter box above any list longer than ten values. Focusing it warms the full value list for that dimension; typing then narrows across every value the dimension has, not only the rows on screen, matching both the stored value and its label.
- A value browser behind “Show all N values”: a search box, an A–Z index with empty letters visibly inactive, values grouped under letter headings with their counts. It stages its selection — clicking a value toggles it in a pending set and the dialog stays open, because the reason to open it is to pick several — and each row is still a real link, so a middle-click or a copied link lands somewhere coherent.
The listing is bounded at two thousand values and says so. The search is not bounded to that listing — it covers every value the dimension has — and the dialog says which of the two is on screen, because they look identical otherwise.
The JSON Facet API has no substring filter. A contains clause inside a JSON facet block is neither honoured nor rejected — it is silently dropped, and measured on a live node it returns the dimension’s most common values whatever you typed. Allowing it would have shipped a search box that lied and was believed. So the search goes through the one classic-facet call in the panel, where the filter genuinely works.