Reported from a downstream re-test batch of platform-capability gaps in Titanwind EHR (private repo: steedos-labs/os-project-titanwind-ehr#1071, gap ③). All facts below are from @objectstack/* 17.0.0 and are self-contained — the downstream links are for provenance only.
Current state (17.0.0)
The field-level related-list surface in @objectstack/spec consists of exactly three keys — relatedList, relatedListTitle, relatedListColumns (spec/src/data/field.zod.ts:788-792). There is no filter dimension at all.
Consequently, the related-list descriptors that RecordDetailView auto-derives for a record page carry only childObject / childLabel / referenceField / isOwned / isPrimary (plus the title/columns overrides above), and the list query is issued directly as { [referenceField]: parentId } — every child row pointing at the parent is shown, unconditionally.
Scenario that breaks
A child object implements soft deletion (e.g. status = 'deleted'). After a user "deletes" a child record:
- the parent's record page still shows the deleted row in the related list, unchanged;
- the related-list tab badge count does not decrease;
- the child object's own list-view filters do not apply to related lists, so there is no declarative way to hide the row anywhere on the auto-derived record page.
Current workaround and its cost
The only way to filter a related list today is to replace the entire page with a hand-written page using the record:related_list component, which does accept a filter input (wired up in objectstack-ai/objectui#3981, from #7118). That works, but the cost is giving up the auto-derived record page for that object — every other related list, layout, and future platform improvement on that page now has to be maintained by hand, to express one filter condition.
Note #7118 is the component-level read point; this issue is the missing declaration-level counterpart, so the auto-derived page can express the same thing.
Request
Add a field-level relatedListFilter key (or an equivalent related-list default-filter declaration) to the spec, and have the auto-derived related lists consume it:
- semantics: AND-composed with the parent-relationship condition
{ [referenceField]: parentId } — an authored constraint, not a user-editable suggestion;
- the tab badge count should honor the same filter, so counts match the visible rows.
Naming/placement is the platform's call — the capability gap is "a declared filter that auto-derived related lists respect".
Reported from a downstream re-test batch of platform-capability gaps in Titanwind EHR (private repo: steedos-labs/os-project-titanwind-ehr#1071, gap ③). All facts below are from
@objectstack/*17.0.0 and are self-contained — the downstream links are for provenance only.Current state (17.0.0)
The field-level related-list surface in
@objectstack/specconsists of exactly three keys —relatedList,relatedListTitle,relatedListColumns(spec/src/data/field.zod.ts:788-792). There is no filter dimension at all.Consequently, the related-list descriptors that RecordDetailView auto-derives for a record page carry only
childObject/childLabel/referenceField/isOwned/isPrimary(plus the title/columns overrides above), and the list query is issued directly as{ [referenceField]: parentId }— every child row pointing at the parent is shown, unconditionally.Scenario that breaks
A child object implements soft deletion (e.g.
status = 'deleted'). After a user "deletes" a child record:Current workaround and its cost
The only way to filter a related list today is to replace the entire page with a hand-written page using the
record:related_listcomponent, which does accept afilterinput (wired up in objectstack-ai/objectui#3981, from #7118). That works, but the cost is giving up the auto-derived record page for that object — every other related list, layout, and future platform improvement on that page now has to be maintained by hand, to express one filter condition.Note #7118 is the component-level read point; this issue is the missing declaration-level counterpart, so the auto-derived page can express the same thing.
Request
Add a field-level
relatedListFilterkey (or an equivalent related-list default-filter declaration) to the spec, and have the auto-derived related lists consume it:{ [referenceField]: parentId }— an authored constraint, not a user-editable suggestion;Naming/placement is the platform's call — the capability gap is "a declared filter that auto-derived related lists respect".