Jetstack does not implement filtering as one universal operator set. Filter behavior is generated by property-family implementations. That is why filtering should be understood from the property family outward.
Two properties may both look like "fields" in the UI, but they can support different operator sets because they belong to different property families.
For example:
- a string property can support
contains
- a datetime property can support date presets and advanced expression-based boundaries
- a system relation property can support subquery-based membership
null and not_null are common across many families.- families may translate generic operator requests into family-specific normalized forms
- list operators rely on the filter-list subsystem
- subquery operators rely on query definitions and relation context
- some property families use translation-aware matching for title-like values
- choose the simplest operator that expresses the business rule clearly
- prefer list or subquery operators when the candidate set is managed elsewhere
- prefer date presets over hand-written date boundaries when the preset matches the requirement