roboto.query.filters

Bases: _FilterBase

True or false, or unset.

Bases: _FilterBase

Instants and ranges. Values are ISO 8601 strings.

The only variant offering relative windows, which is where the fidelity problem this whole model exists for actually bites.

Bases: _FilterBase

Equality against a closed set of options.

Every filter variant, keyed by its type discriminant.

One filter row. type selects the variant, and with it the operators on offer.

Bases: roboto.compat.StrEnum

How separate filters combine.

Bases: roboto.compat.StrEnum

Operators a saved filter needs that Comparator cannot express.

Every member is a gap in the query language, and this enum is the list of them. It is the complement of Comparator, never a superset: a member here that Comparator can express is a stale entry.

Members are removed one at a time as Comparator grows to cover them. The wire values do not change when that happens, so filters saved beforehand keep parsing.

Which operators each principal type contributes, and the only statement of that pairing.

Exhaustive over RobotoPrincipalType rather than listing the types an audit column happens to hold today, so a new platform principal type is filterable as soon as it exists instead of being silently unaddressable. A test pins that.

The IS_ANY_<TYPE> half. Valueless: the comparator alone carries the predicate.

The principal type each identity operator addresses. Derived from the pairing above.

Bases: roboto.compat.StrEnum

Operators over a principal-valued field, where the operator names a principal type.

An audit column such as created_by stores a fully-qualified principal — user:<user_id>, device:<device_id>@<org_id>, invocation:<invocation_id> — so “created by a user” is a question about the type prefix and “created by this user” a question about the whole value. Putting the type in the operator is what lets a filter UI offer the matching directory to pick from, instead of asking for a hand-typed prefix.

Each type contributes two operators (see IDENTITY_OPERATORS_BY_TYPE): a value-bearing IS_<TYPE> and a valueless IS_ANY_<TYPE>.

Separate from FilterOnlyComparator because these are not gaps in the query language. Both halves are expressible as a query today — IS_<TYPE> as EQUALS against each picked principal, IS_ANY_<TYPE> as LIKE '<type>:%' — so they are never removed. They are a filter-control affordance, and they outlive the gap enum.

Bases: _FilterBase

A principal-valued field, filtered by principal type.

Audit columns (created_by, modified_by) hold a fully-qualified principal string, so the operator names the type (IdentityComparator) and any values it takes are principals of that type — an IS_USER filter carrying a device: value is rejected, since it records an intent the picker cannot express and a query cannot satisfy.

Values are labeled options rather than bare strings: a principal id is not a name a reader can place, so the directory’s display name is captured alongside it at pick time.

Has no presence axis. Every write path stamps an audit principal, so the column is never null and a null check would be an operator that always answers the same way.

Bases: NamedTuple

The operator pair one principal type contributes to an identity field’s menu.

Bases: pydantic.BaseModel

One option as it was picked: the value a query is built from, plus what the picker showed.

Both halves are stored because the label cannot be recovered later. An opaque value — user:usr_01J..., a tag id — renders as itself, and resolving it on load would mean a directory lookup per chip, against an org that whoever opens a shared View may not be able to read. Only value ever reaches a query.

Prefix distinguishing a user-defined metric from an ordinary numeric property.

Metric filters store the prefixed form so that field means the same thing here as it does in a Condition, and translating a filter into a query copies the field across rather than special-casing it.

A metric’s dot-delimited path, carrying its metric. prefix.

Bases: _FilterBase

Ordering and equality over a user-defined metric.

Numeric in every respect except that field is a metric path. Kept a distinct variant so a client restoring a View knows to reopen the metric picker rather than the property form, which it cannot infer from the field name alone.

Carries the presence pair like any other scalar type. A session may simply have no such metric recorded, and the session query path answers that directly — it maps IS_NULL to a NOT EXISTS over the metrics table.

Bases: _FilterBase

Ordering and equality over a numeric property.

Null checks. Valueless: the comparator alone carries the question.

Relative windows. Valueless: the comparator alone carries the range.

Bases: pydantic.BaseModel

A complete set of filter controls, as saved.

Bases: _FilterBase

Membership in a collection-valued field, such as tags.

Has no presence axis: an empty collection is not the same as an absent one, and the UI offers no null check here.

Bases: _FilterBase

Text matching.

The operators each filter type offers, as wire values.

Derived from the models rather than restated, so it cannot fall out of step with what they actually accept. Two callers: anything building a filter that needs to know what is valid for a field type, and the drift check against the filter UI’s own copy of this vocabulary — there is no code generation between the two, so a test compares them.