#[non_exhaustive]pub enum Operator {
And,
Or,
Not,
}Expand description
Logical operator for combining filter conditions (RFC 8620 §5.5).
§Excluded from extras preservation
This enum is out of scope for the workspace extras-preservation policy:
it carries no Other(String) catch-all variant, and backends must
dispatch on its known variants (AND, OR, NOT) to evaluate a filter
tree. An Other operator would be meaningless — a server that cannot
interpret the operator cannot evaluate the filter, and silently round-
tripping it back to the client would yield wrong query results.
More broadly, filter algebra (this enum and the per-object
FilterCondition / Comparator types) is excluded because unrecognised
filter clauses are a query-correctness hazard: silently dropping or
round-tripping a clause the server does not understand can return the
wrong set of records to the client without any error signal.
§What to do instead
IETF-track path. Vendors who need both capability-level declaration
and filterability for custom fields should use
draft-ietf-jmap-metadata (capability URI
urn:ietf:params:jmap:metadata), which defines a Metadata / Annotation
companion object keyed by (relatedType, relatedId) with schema discovery
via the capability’s metadataTypes / maxDepth properties and a
Metadata/query filter. Implemented in jmap-metadata-types,
jmap-metadata-server, and jmap-metadata-client (bd JMAP-06zp).
Pre-IETF escape. Vendors who cannot wait for the metadata draft can
either escape the filter tree to serde_json::Value or fork the
per-crate FilterCondition type. See
crate-jmap-calendars-types/PLAN.md for the hybrid sloppy-value
pattern.
Cross-reference: bd JMAP-lbdy “Decision: filter algebra excluded”.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
And
Logical AND: all sub-filters must match (RFC 8620 §5.5).
Or
Logical OR: at least one sub-filter must match (RFC 8620 §5.5).
Not
Logical NOT: none of the sub-filters may match (RFC 8620 §5.5).