record:related_list.filter 声明了却无人读:RelatedList 的列表查询只按父关系过滤,作者写的 filter(以及 dataSource 合成出的 filter)整条丢弃

[yinlianghui]

发现于 objectstack#6953 的实施过程(objectui 分支 claude/issue-6953-datasource-block-wiring)。不在该单范围内(它只做 dataSource 逐 block 接线),单独立单。

事实(objectui origin/main @ 65bb513dc 实测)

record:related_list 的注册 inputs 明确声明了 filter:

packages/plugin-detail/src/index.tsx:  { name: 'filter', type: 'array', label: 'Filter', description: 'Additional filter criteria' },

但渲染器从不读它 —— packages/plugin-detail/src/renderers/record-related-list.tsx 里 grep filter 只命中 columns 的 FLS 过滤(rawColumns.filter(...))与注释,传给 RelatedList 的 props 里没有任何 filter 通道:

title / type / api / objectName / referenceField / parentId / columns
pageSize / defaultSort / dataSource / add / rowActions / ... 

RelatedList 侧也没有对应的入口:它的列表查询完全由父关系构成(packages/plugin-detail/src/RelatedList.tsx,fetch 处 const filter = { [referenceField!]: parentId }),filter 相关的 prop 只有 add.picker.filter(Add 选择器的 baseFilter,#3831 接的)和客户端搜索框 filterable/filterText,都不是列表自身作用域。

症状

作者按已发布的 inputs 给相关列表写 filter: [['is_active','=',true]],得到的是该父记录下的全部子行 —— 不报错、os validate / SDUI 保存门也全绿(filter 是已声明键,sdui-parser 的 prop walk 不会报 unknown-prop)。这正是 objectstack#4413 的形状:声明了、验证通过、没人消费。

与 objectstack#6953 的关系(为什么单独立单而不是并进去)

#6953 把 spec 的 PageComponentSchema.dataSource 逐 block 接到各自读的键上。record:related_list 那一块故意没有映射 filter:把合成出来的 filter 写到一个没人读的键上,只是把 #6953 要消除的缺陷往下挪一层、看起来像接好了。#6953 的 PR 里为此钉了一条诚实的反向断言(RecordRelatedListRenderer.elementDataSource.test.tsx 最后一例:确认没有任何 filter 到达 RelatedList),并在 content/docs/guide/data-source.md 的逐 block 覆盖表里写明了这个缺口。

连带后果(比单独的 flat 键更重):在 record:related_list 上写 dataSource: { object, view } 时,saved view 的 columns/sort/limit 会生效而它的 filter 被丢弃 —— 于是列表比它引用的那个 view 更宽。「命名了 view 却静默放宽」正是 objectstack#5576 立下的语义要禁止的方向,只是这里的根因在 flat filter 无读点,不在合成逻辑。

修完后 #6953 侧的收尾(一行)

filter 拿到读点后,RECORD_RELATED_LIST_DATA_SOURCE(record-related-list.tsx)加上 filter: true,绑定侧即自动跟上;上面那条反向断言同时翻转。

建议范围

1. RelatedList 增加列表自身作用域的 filter 入口,与父关系条件 and 合成(不要走 lookupFilters —— 那会渲染成用户可编辑的筛选行,把作者的约束变成建议,fix(automation,objectql): a filter that loses a condition must not run (#3810) #3831 已论证过)。
2. record-related-list.tsx 把 schema.filter 接上去。
3. 两方向钉子:带 filter 时进入查询、不带时与现状逐字节一致。
4. 顺带确认 inputs 里 filter 的 type: 'array' 与实际接受的形状一致(spec 的 ViewFilterRule[]?MongoDB 风格条件对象?),不一致就以 spec 为准修 inputs 描述。

Blocked-by: #6953

---

Generated by Claude Code

[claude]

Triage: pm:blocked; body line Blocked-by: #6953 added (routing repo:objectui kept as filed).

• Classification: real defect (declared record:related_list.filter has no read point — verified: packages/plugin-detail/src/index.tsx:323 declares it, RelatedList.tsx:457 builds the query filter solely as { [referenceField]: parentId }), and the fix shape is concrete. Queue-class on its merits.
• Why blocked rather than queued: the card's close-out steps flip PageComponentSchema.dataSource 在 list-view 之外仍无人消费:element:record_picker 丢 view,object-grid/form/kanban/calendar 等整条绑定不读(按 spec 写 dataSource 渲染出空) #6953's reverse assertion (RecordRelatedListRenderer.elementDataSource.test.tsx) and extend RECORD_RELATED_LIST_DATA_SOURCE — both exist only on PageComponentSchema.dataSource 在 list-view 之外仍无人消费:element:record_picker 丢 view,object-grid/form/kanban/calendar 等整条绑定不读(按 spec 写 dataSource 渲染出空) #6953's in-flight PR branch (zero hits for RECORD_RELATED_LIST_DATA_SOURCE on objectui origin/main @ 53b7b88). Landing this first guarantees a same-file collision with a dispatched card. PageComponentSchema.dataSource 在 list-view 之外仍无人消费:element:record_picker 丢 view,object-grid/form/kanban/calendar 等整条绑定不读(按 spec 写 dataSource 渲染出空) #6953 is open, pm:dispatched, in flight.
• Dedup: deliberately disjoint from PageComponentSchema.dataSource 在 list-view 之外仍无人消费:element:record_picker 丢 view,object-grid/form/kanban/calendar 等整条绑定不读(按 spec 写 dataSource 渲染出空) #6953 (wiring card; its mapping intentionally omits filter) and PageComponentSchema.dataSource 在剩余 object-bound public block 上仍无人消费:object-gantt / object-timeline / object-map / object-pivot / object-master-detail-form / embeddable-form(按 spec 写仍渲染出空) #7121 (remaining blocks); clean.
• Unlock duty: on PageComponentSchema.dataSource 在 list-view 之外仍无人消费:element:record_picker 丢 view,object-grid/form/kanban/calendar 等整条绑定不读(按 spec 写 dataSource 渲染出空) #6953's merge, re-verify the read-point situation at the merged ref before dispatch.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[yinlianghui]

PM 分诊(objectui 分片,session_01GTRjn8xBqp75dk7kFupVRt):晋级 pm:queue —— record:related_list 的 filter input 声明了但实现不读,属「声明面对作者撒谎」的具体缺陷(#3226 同族);PR #3969 已把诚实后果钉住(filter 不达 RelatedList、命名 view 的 filter 被丢)。修法方向留实施者按 #0.1 论证(接通 vs 撤声明),两侧都要动到 RelatedList 的查询合成 —— 建议与 objectui#3895(Add 按钮不判 dataSource,同文件)同批,PR3969 合入后解锁。

---

Generated by Claude Code

[yinlianghui]

🔒 认领(objectui 分片 PM,session_01GTRjn8xBqp75dk7kFupVRt,批次 4 补位;代码落 objectstack-ai/objectui)—— 与 objectui#3895 结对一 PR,分支 claude/issue-7118-3895-relatedlist-gates(同文件 RelatedList.tsx)。本单的 filter 死声明按分诊评论:接通 vs 撤声明由实施者按 AGENTS.md #0.1 论证后定,PR3969 已钉的诚实后果钉同步更新。

---

Generated by Claude Code