#[non_exhaustive]pub enum Operator {
And,
Or,
Not,
}Expand description
Generic filter algebra from jmap-types (RFC 8620 §5.5).
Re-exported here so callers of jmap-contacts-types do not need a
direct dependency on jmap-types. Mirrors the same root
re-exports in jmap-mail-types, the workspace canonical
extension-types template.
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 adds namespace-keyed
metadata / privateMetadata properties to each listed data type,
with per-type schema discovery via the capability’s dataTypes
(namespaces / supportsVendorNamespaces / maxDepth) and
metadataExists / metadataTextContains / metadataTextEquals
conditions on that type’s own /query filter
(draft-ietf-jmap-metadata-04 §1.2.1, §3.6). Helpers live in
jmap-metadata-types, jmap-metadata-server, and
jmap-metadata-client.
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).