fix(studio): hold a dashboard Global Filter whose Options From is begun but not finished - #29300

Requested by Steedos · project thread

Fixes #29006

Clause-②: no
Metadata-protocol: none

Claim 6574490931.

维护者速读

• 改了什么:Studio 仪表盘属性里的「全局筛选」条目,如果「选项来源」只填了对象、还没填值字段和标签字段,这个条目现在会先保留在编辑器里、不自动保存;顶部出现一行中性提示(英文界面为 “Not saved yet: Options From on item Add metamodel interfaces for ObjectQL/ObjectUI contract #1 of “Global Filters” needs a value”),填完后一次性保存期间的所有修改。
• 为什么改:原来空条目会被保留,但「填了一半」的嵌套输入会被当成已完成直接自动保存,服务端 422 拒收;之后改描述、改标签每次都带着这个条目被拒,刷新时没有离开提示,修改全部丢失。
• 风险与回滚:只改一个判断函数 listItemHeldInput:条目里任何一层「尚未填写」的输入都算未完成;作者已经填了值但值不合法的情况照常发送并显示红色拒收,不会被藏起来。仪表盘与报表的列表条目都走这条规则。回滚即 revert 本 PR。
• 先看:ui/packages/app-shell/src/views/studio-design/metadataError.ts 的 listItemHeldInput(向下逐层找未填写值的循环);metadataError.heldNestedInput-29006.test.tsx(保留与不保留两侧,以及真实自动保存路径)。
• 两分钟验证:Studio 打开一个可写包里的仪表盘 → 属性 → Filters → Global Filters → Add item,填 Field、Input Type 选 select、Options From 只填 Object,再改一下标签:网络里没有仪表盘的 PUT,顶部出现上述提示;再填好 Value Field 和 Label Field,出现一次 200 的 PUT,带着标签修改。
• 需要你做的:无,席位落地。

What changes

• listItemHeldInput follows each refusal down from the item. It held an item only when every issue named an unset input directly below it (path[at + 1]). A Global Filter with optionsFrom: { object } draws issues at optionsFrom.valueField and optionsFrom.labelField, whose direct input optionsFrom holds a value, so the item read as finished but wrong and was sent. The rule now walks the issue's path down from the item, through objects and list indexes, and holds the item when it meets a value left unset (absent, or a text cleared to blank) at any depth. A step through a value the author gave that has no such key (a text, a number) meets none.
• The input named stays the item's own form row (optionsFrom, shown as "Options From"), so heldListItem and the clause are unchanged: "Options From on item Add metamodel interfaces for ObjectQL/ObjectUI contract #1 of “Global Filters” needs a value".
• Finished but wrong work is still sent. An item whose issues include a value the author gave that the spec refuses, at any depth, is not held, so its refusal shows as before.
• The dashboard list callers (dashboardHeldEdit) and the report list callers (reportHeldEdit) get it through the same function. No per-field case for optionsFrom. GlobalFilterSchema.optionsFrom in packages/spec is unchanged. StudioDesignSurface.tsx is unchanged: the surface's existing hold (leafIncomplete, the autosave's blocked, the held line, the leave guard, Publish) applies as it does to the empty item.

Tests

• metadataError.heldNestedInput-29006.test.tsx (new). Unit cases on listItemHeldInput / dashboardHeldEdit, each paired with DashboardSchema's own verdict on the same body:
  • held: Options From with its Object only (issues at optionsFrom.valueField and labelField), named "Options From"; Options From missing only its Label Field;
  • still held: a direct unset input (field), the empty-item case;
  • not held: a nested value the author gave that the spec refuses (labelField: 42); an unset nested input beside a refused nested value; optionsFrom given a text where the spec wants an object; a Label Field cleared to blank, which the spec takes; a finished Options From.
• The same file mounts the Interfaces pillar with the real DashboardDefaultInspector (as InterfacesPillar.heldListItem-27459.test.tsx does): a saved select filter, then Options From → Object and a Label edit send no dashboard save, show no red strip, show the held line and report the clause to the surface; filling Value Field and Label Field sends one save carrying the Label edit and the finished filter, which DashboardSchema accepts.

Acceptance notes

• The card's Expected reads "the partly filled item is held like the empty one (or the refused edits are guarded on leave)". This PR does the first. While held, the surface's leave guard is armed (measured below), so a reload asks first.
• Deviation from the dispatch wording: it described the held outcome as "the draft autosave leaves the item out and the other edits save". The existing hold does not save around the item: nothing is sent while the item is held, and the next save after it is finished carries every edit kept meanwhile (as the empty-item hold behaves). The surface test pins that behaviour.
• The doc comment on HeldListItem.input ("the item's input the spec refuses it without") and the section header above it still read as direct-input wording; both are outside this card's surface (listItemHeldInput and its doc comment only) and were left as they are.

Verification

🤖 Generated with Claude Code

https://claude.ai/code/session_01QsR2jSRsNRkCr8sZjG6Cpz