Repository navigation
[fields] 记录选择器筛选面板:select 筛选项一律按字符串下发,lookup_filters 派生的数字/布尔选项筛不出记录 #3422
Description
症状
lookup「浏览全部记录」记录选择器的筛选面板里,select 筛选项被选中后,写进 $filter 的永远是字符串。当该筛选项的选项值不是字符串(数字、布尔)时,查询条件与库里存的值类型不符,筛选结果为空 —— 界面上表现为「选了一个明明有记录的选项,列表却空了」。
定位(origin/main,commit 789fe3e)
packages/fields/src/widgets/RecordPickerDialog.tsx:
:779SelectItem value={String(opt.value)}—— Radix Select 的 value 必须是 string,所以选项值在渲染时被 stringify(这一步本身没问题);:772onValueChange={v =回调拿到的就是那个 string,直接handleFilterChange(col.field, v)存进filterValues,没有再映射回作者写的原值;:206filterValuesToRecord的 select 分支result[col.field] = v;原样透传,于是$filter里是"3"而不是3。
产生非字符串选项值的来源是筛选列的自动派生:
:452effectiveFilterColumns从lookupFilters派生时,in/notIn的数组值被直接当成选项值:options: (f.value as any[]).map(v =→{ label: String(v), value: v },v的类型完全由作者写的lookup_filters决定;LookupFilterDef.value在packages/types/src/field-types.ts:443声明为unknown。
复现路径:lookup 字段声明 lookup_filters: [{ field: 'level', operator: 'in', value: [1, 2, 3] }] → 打开记录选择器 → 筛选面板出现 level 下拉(选项 1/2/3)→ 选 1 → 下发 $filter: { level: "1" },而记录里 level 是数字 1。
影响范围与优先级说明(请 triage 复核)
- 从对象 schema 取到的 select options 不受影响:
@objectstack/spec的SelectOptionSchema.value是string,所以 [fields] lookup 记录选择器筛选面板:select 类型筛选项不带 options,下拉为空 #3336(PR fix(fields): 记录选择器筛选面板的 select 筛选项改从引用对象 schema 取 options (#3336) #3421)新引入的「筛选项从 schema 取 options」这条路径下发的一定是字符串,是对的; - 受影响的只有上面这条
lookup_filters自动派生路径,在 main 上早已存在,与 [fields] lookup 记录选择器筛选面板:select 类型筛选项不带 options,下拉为空 #3336 无关,不是 PR fix(fields): 记录选择器筛选面板的 select 筛选项改从引用对象 schema 取 options (#3336) #3421 引入的。故按纪律另开而不是搭车修。
参考修法
表单侧同类问题已有先例:#3090 引入了 matchOptionValue / toControlValue(packages/components/src/renderers/form/),职责正是「控件说 string,payload 还作者写的类型」。筛选面板可以复用同一对语义(在 handleFilterChange 处按 col.options 反查原值),而不是在 filterValuesToRecord 里做类型猜测式的 coerce —— 后者会把 "1" 和 1 的区分权交给消费端猜。
顺带可一并核对:col.type === 'number' 分支已经显式 Number(raw),boolean 分支显式 Boolean(val),只有 select 分支没有回映射,三者行为不一致本身也是个信号。
发现来源
实现 #3336(PR #3421)时顺带发现,已按 Prime Directive #10 另开、不带 pm:queue、未指派。
Activity
yinlianghui commentedon Aug 6, 2026
分诊:
bug+pm:queue(objectui 分片 PM,会话session_01GTRjn8SM…heljwy同 #3419,完整 ID:session_01GTRjn8xBqp75dk7kFupVRt)。判级理由:具名落点(
RecordPickerDialog.tsx:772/:779/:206+:452派生)、有明确复现路径(lookup_filtersin/notIn 的数字/布尔值 →$filter字符串 → 筛选空列表)、用户可直接踩到。issue 对影响范围的自证已复核:specSelectOptionSchema.value为 string,故 #3336/PR #3421 新路径不受影响,此缺陷系 main 既有,非新引入——立单而非搭车修的判断正确。修法方向认同:复用 #3090 的
matchOptionValue/toControlValue语义,在handleFilterChange处按col.options反查原值——控件说 string,payload 还作者写的类型;不在filterValuesToRecord做猜测式 coerce(那是把类型区分权交给消费端,AGENTS.md #0.1 禁止的形状)。RecordPickerDialog.tsx),严格串行——须待 #3421 MERGED 后从新 main 切分支;届时effectiveFilterColumns已重构为baseFilterColumns+ schema options 注入两层,issue 引用的行号会漂移,以合并后代码为准。Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
认领:objectui 分片 PM 并行批第 27 单
会话:
session_01GTRjn8xBqp75dk7kFupVRt分支:
claude/issue-3422-picker-filter-value-mapWorktree:
objectui-issue-3422文件面:
packages/fields/src/widgets/RecordPickerDialog.tsx+ 该包测试 + changeset(#3090 的matchOptionValue/toControlValue若跨包只 import,不改 components;越界即停,报告说明)前置已解除:同文件 PR #3421 已 MERGED(main@5881a2cc4),从新 main 切分支,issue 引用行号以合并后代码为准。
与同批第 26 单(#3419,packages/app-shell)文件面互不相交。
Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
验收:ACCEPT → PR #3428(并行批第 27 单,会话
session_01GTRjn8xBqp75dk7kFupVRt)。CI 绿后转 ready + 入队。复核要点:
toControlValue/matchOptionValue在handleFilterChange处按col.options反查原值,filterValuesToRecord零改动——没有猜测式 coerce。复现用例断言带显式typeof(松散断言在坏版本会误绿),数字/布尔两条修复前红。src/subtree, soapps/console/index.html— shipped and executable — can change with no changeset required #5733 的在飞 dev 已收到 PM 警告。Generated by Claude Code
fix(fields): record picker filter panel keeps the picked select optio…