Skip to content

Auto-derived related lists consume the new field-level relatedListFilter declaration — list query AND-composed, tab badge honors the same filter #4664

Description

@os-zhuang

Downstream half of objectstack-ai/objectstack#8704, filed by the domain:spec seat under the contract-first split the maintainer ruled 2026-08-15 (「接受全部建议。」, item 3 — the four binding conditions are recorded on that card).

Blocked-by: objectstack-ai/objectstack#8704

What

Once the spec half lands (a relatedListFilter key joining the existing family at field.zod.tsrelatedList / relatedListTitle / relatedListColumns), the auto-derived related-list descriptors that RecordDetailView builds for a record page must consume it:

  1. the list query becomes the declared filter AND-composed with { [referenceField]: parentId } — an authored constraint, never a user-editable suggestion;
  2. the related-list tab badge count honors the same filter, so counts match visible rows;
  3. the declared filter reuses the platform's existing declarative filter shape — no new dialect on this side either (the component-level record:related_list filter input from objectstack#7118 / PR fix(plugin-detail): record:related_list 的 filter 接通查询,Add 按钮门与 picker 对话框对齐 (objectstack#7118, #3895) #3981 is the nearest existing read point and should share plumbing where honest).

Scope guard

⛔ Do not start before the upstream spec key is MERGED and the pin covers it — the exact key name and shape are the upstream card's to settle. ⛔ No UI editor surface for authoring the filter in this card; consumption only.

Provenance: the driving scenario is soft-deleted child rows on auto-derived record pages (Titanwind EHR, gap ③ — see the upstream card).

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions