1.6.1

Released: 2026-06-03

Highlights

• Landing pages can now be filtered by tag (and any array-backed column) — for example, items by tagIds — which was previously silently ignored.
• Pagination totals on grouped landing pages (e.g. items) are now correct.

Added

• Array / aggregate column filtering on findLandingPages / findLandingPageKpis. Membership filters (IN/EQ/NOT_IN/NE) on array columns such as tagIds (UUIDs) and tags (names) translate to a PostgreSQL array-overlap (&&) condition, applied in HAVING for aggregate columns. See Landing-Page Array/Tag Filters.

Changed

• The internal build_filter_condition now returns a BuiltCondition carrying a WHERE/HAVING target; apply_filters buckets conditions per clause. No GraphQL schema change.

Fixed

• findLandingPages(sourceType: ITEMS) filters on tagId/tagIds were silently dropped (singular field didn't exist; plural blew up parsing list[uuid.UUID]).
• total on grouped landing statements counted rows within the first group instead of the number of groups; it now wraps the grouped statement in a subquery.

Migrations

• None. No schema change in this release.

Frontend impact

• Filter items (and future array-backed landing columns) by tag with columnName: "tagIds" (UUIDs) or columnName: "tags" (names), operator IN. Each value matches "row has any of these"; send one filter per value inside an OR group, or a JSON array to a single filter, to match several.
• NOT_IN / NE mean "row has none of these" and include rows with no tags.
• Combining a tagIds filter with a row-level column filter using operator: OR in the same group is supported — the row-level leg is promoted into HAVING via bool_or(...) so it behaves as a true OR.
• Grouped landing-page total values (items) are now accurate; update any UI that worked around the previously wrong count.

Versioning notes

• PATCH bump (scripts/bump_version.py 1.6.1 --changelog-stub): additive filter capability + bug fixes, no breaking schema change. No deploy-order constraints.