Skip to content

finding(plugin-grid): DATA_SOURCE_WIDGET_TYPES 是「哪些 widget 要 DataSource」的第四份私有副本 —— 与表单规则不同集、零 gate #4815

Description

@yinlianghui

发现于 #4790 的实施。同 #4770 / #4790 的失效模式,不在 #4790 范围内(该卡正文只点名两张表),单独立此单记录。

事实(实读 origin/main @ f2dc8fa)

packages/plugin-grid/src/components/bulkParamToField.ts:40-46:

const LOOKUP_WIDGET_TYPES = new Set(['lookup', 'master_detail']);
const USER_WIDGET_TYPES = new Set(['user', 'owner']);
const DATA_SOURCE_WIDGET_TYPES = new Set([...LOOKUP_WIDGET_TYPES, ...USER_WIDGET_TYPES]);

消费点两处:fieldNeedsDataSource()(→ BulkActionDialog.tsx:600 决定是否把网格的 DataSource 传给 param 控件)与 isLookupishParam()(→ 决定是否补 reference_to / display_field)。

它编码的正是对象表单那条规则的同一件事 ——「这个 widget 要查记录,所以得把 DataSource 递给它」—— 但成员是第三种集合:

成员
@object-ui/core EXPANDABLE_FIELD_TYPES(schema 字段类型域) lookup, master_detail, tree, user
表单 needsDataSourceWiring(widget 键域,#4790 后派生自上表) lookup, master_detail, tree, user + object-ref, filter-condition, recipient-picker
plugin-grid DATA_SOURCE_WIDGET_TYPES(widget 键域) lookup, master_detail, user, owner

即:多 owner,少 tree 与三个 widget-hint picker。没有任何 gate 能发现它继续漂。

为什么今天没有用户症状(据此判为 observation-class)

所以现状是「三份写法各自恰好够用」,不是线上缺口 —— 但这正是 #4770#4790 两次都描述的前夜状态:注释声称同步、机制不保证,直到某一侧加键才炸。

修法方向(与 #4789 / #4790 同型)

单一定义 + 各消费面自己做归一化 + identity 钉(钉对象身份,成员相同的私有副本骗不过)。落点候选:core 的 EXPANDABLE_FIELD_TYPES(参考半)+ 各面自己的 widget-hint 扩展,与 #4790 给表单定的形状一致。owner 那一格取决于 #4814 的裁决,建议#4814 判完再动,否则会把一个待退役的别名钉进共享表。

Blocked-by: #4814

参考

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions