v0.1.87 — 23 Jul 2026
Feature — Native support for _in and _nin in aggregate query filters
Who is affected: Developers and API clients calling aggregate queries (e.g. /api/items/[collection]?aggregate[count]=*) with filters.
What was wrong
Previously, when combining aggregate operations (such as count, sum, avg, min, max) with a filter using _in or _nin operators, the backend query failed. The database helper function _build_filter_clause lacked handler cases for _in and _nin, raising an Unsupported filter operator in aggregate: _in exception.
What changed
We updated the database function to support these operators natively:
- Database Migration: Added a migration file
supabase/migrations/20260721000001_add_in_nin_to_aggregate.sqlthat updates the PostgreSQL helper function_build_filter_clauseto natively support_inand_ninoperators as SQLIN/NOT INexpressions. - Null Safety: Handles SQL three-valued logic by stripping out
nullelements inside_ninarrays to ensure query execution does not erroneously exclude all rows. - Robust Test Coverage: Added exact-count regression tests in
tests/api/items-aggregate.spec.tscovering both standard filters and the reported scenario on theinventorycollection.
| Filter Query Type | Before | After (v0.1.87) |
|---|---|---|
filter[status][_in]=active | ❌ Unsupported operator: _in | ✅ Natively resolves to SQL IN |
filter[status][_in]=active,pending | ❌ Unsupported operator: _in | ✅ Natively resolves to SQL IN |
filter[status][_nin]=draft,archived | ❌ Unsupported operator: _nin | ✅ Natively resolves to SQL NOT IN |
Feature — Dynamic Badge Collection Selector for Relationships
Who is affected: Platform Studio developers configuring database relationships (Many-to-One, One-to-Many, Many-to-Many).
What was wrong
Previously, the related collection in relationship configurations was rendered as a static, plain Badge element. Developers could not interactively select or switch the related collection from the relationship panel, requiring manual input or extra steps which were prone to typos and reference errors.
What changed
Introduced the BadgeCollectionSelector component and integrated it into the RelationshipConfiguration panel:
- Interactive Dropdown Badge: The related collection badge is now a dynamic dropdown menu that lists all available collections.
- Categorization: Collections are dynamically fetched from the
/api/collectionsendpoint and divided into User Collections and System Collections (prefixed withdaas_). - Singleton Prevention: User collections configured as singletons (
col.meta?.singleton === true) are automatically disabled in the selection list to prevent creating unsupported relationships pointing to single-row collections. - Readonly in Edit Mode: The selector is disabled when editing an existing field (
isEditing={isEditing}) to preserve database schema integrity.
Feature — Relational Interface Option & Relationship Config Sync
Who is affected: Platform Studio developers working with Many-to-One (M2O) field interfaces like collection-item-dropdown.
What was wrong
When setting up relational fields (specifically collection-item-dropdown, select-dropdown-m2o, and list-m2o), the interface-specific options (e.g., target collection to pull items from) and the database relationship configuration (e.g., foreign key references) could easily go out of sync. Developers had to coordinate these manually, leading to validation errors and invalid foreign keys. Additionally, attempting to synchronize them naively resulted in React infinite render loops.
What changed
Updated FieldDetailModal to align interface option fields and relationship metadata:
- Auto-configuration: Selecting
collection-item-dropdown,select-dropdown-m2o, orlist-m2ointerfaces automatically populates default M2O configurations withon_delete: "SET NULL". - Bidirectional Sync: Modifying the target collection in the
collection-item-dropdowninterface options automatically updates the relationship configuration, and vice versa. - Render Loop Prevention: Implemented a state synchronization tracker (
lastSyncedCollectionRefref) to safely synchronize options and relationship configurations without causing infinite React render/update cascades.
Changed — Removed custom table/list styling in favor of microbuild-ui/ui
Who is affected: Platform Studio developers viewing and managing collection data lists.
What was wrong
The collection page layout contained hardcoded custom <style> overrides to enforce table/list sizing and flex alignment. This styling was rigid and conflicted with standardized component design systems.
What changed
Removed the inline <style> overrides from the collection view:
- Style Cleanup: Removed the custom CSS tag overriding
.collection-list,.v-table, and pagination margins in CollectionPage. - Design Alignment: Relies on standardized styling provided by the UI components from
microbuild-ui/ui.
Docs — Comprehensive OpenAPI / Swagger Specification Coverage
Who is affected: Developers exploring and testing DaaS endpoints using the /api-explorer UI.
What changed
We scanned the entire app/api directory and brought the Swagger specification in lib/swagger/paths.ts to 100% parity with actual route handlers.
New endpoints documented:
/api/health[GET] — Simple liveness/uptime check./api/interfaces[GET] — Field UI interface components configuration metadata./api/ext/{path}[All Methods] — Catch-all routing gateway proxy for custom extensions.
Added missing methods to existing endpoints:
/api/activity→ Added [DELETE] (admin housekeeping log purging)./api/fields/{collection}→ Added [POST] (creates a new collection field)./api/folders→ Added [DELETE] (bulk folder deletion)./api/permissions→ Added [DELETE] (revokes policy permissions by query).