fix(plugin-detail): 声明的展示 type 只能收窄内联编辑,永远不得放宽 (#3355) - #3357
Merged
Conversation
…ever widens it (#3355) Both detail-surface editability gates resolved ONE effective type with display precedence (`viewFieldType || objectFieldType`), so an authored non-computed `type` erased the object's `formula`/`summary`/`rollup`/`auto_number` declaration from the gate's view and made a machine-owned column inline editable. That is the shipped configuration behind objectstack#5077: the reporter writes `{ name: 'supply_share', type: 'number' }` purely to fix formatting (a workaround for objectstack#5066) over a hook-maintained ROLLUP. The header chip became writable, the rollup was overwritten by hand and stayed corrupted until an unrelated child-row touch re-fired it (yinlianghui/hotcrm-heimao#61). The gate now takes the UNION of the two types: non-editable if the authored entry type OR the object field's type is computed. Renderer/editor selection keeps the old precedence, so the display is unchanged — only who may write. - fieldEnrichment: new `isComputedFieldType(viewFieldType, objectFieldType)`, the ONE definition both gates call; `TEXTUAL_REF_FALLBACK_TYPES` moved here beside it (still re-exported from InlineFieldInput, public name unchanged) so the renderer fallback and the two gates read one set. - HeaderHighlight / DetailSection: gates pass the authored type and the object type separately instead of the collapsed `resolvedType`. - tests: 23 cases across both surfaces — the reporter's exact config named, every computed object type under an authored `number`, narrowing still working, plain-field controls, and the #3356 `readonly` regression guard. 13 of them fail against the pre-#3355 precedence logic. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ehu85kbvMcrNTUJjwxvLJ9
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3355
关联:objectstack-ai/objectstack#5077(上游一家的现场)、下游 yinlianghui/hotcrm-heimao#61(被手工覆写的 rollup)、objectui#3356(同一条链上的
readonly修复,已合并)。问题
两个同形的可编辑性门(
HeaderHighlight表头高亮条、DetailSection详情正文)此前都把「有效类型」收敛成一个值,用的是展示优先级viewFieldType || objectFieldType。于是作者写在视图条目上的展示type会替换掉对象字段的类型,把对象上formula/summary/rollup/auto_number的声明从门的视野里抹掉,平台维护的列因此变成可内联编辑。这不是假想:报 objectstack#5077 的那家 app 就是这么发的 —— 为了绕过 objectstack#5066 的展示格式问题,他们在条目上写了
{ name: 'supply_share', type: 'number' },而supply_share是 hook 维护的 rollup。表头 chip 于是可写,值被手工覆写后一直错着,直到一次无关的子行变更重新触发 rollup 才被纠正。修法(issue 里的 Option A,维护者 2026-08-04 定调)
门改成取两个类型的并集:authored 条目类型 或 对象字段类型任一为计算类型,即不可编辑。渲染器/编辑器的选择保持原有优先级不变,所以展示效果一点不变 —— 变的只是「谁能写」。
规则一句话:声明的展示
type只能收窄可编辑性,永远不得放宽。 对象 schema 才是「这一列是否由机器维护」的权威;展示层的覆写没有资格授予写权限。收窄仍然有效 —— 在普通列上写type: 'formula'依旧能锁死它。共享而非镜像
新增
isComputedFieldType(viewFieldType, objectFieldType),放在packages/plugin-detail/src/fieldEnrichment.ts—— 正是两个宿主已经共享、且当初就是为了阻止这类 drift 而建的模块(issue 正文点名了这一点)。计算类型集合TEXTUAL_REF_FALLBACK_TYPES一并挪到那里(InlineFieldInput原样 re-export,包的公开导出名不变),这样「渲染回退」和「两个可编辑性门」读的是同一份定义,不可能再各修各的。改动文件:
packages/plugin-detail/src/fieldEnrichment.ts—— 集合 + 新 helper(带完整的来龙去脉注释)。packages/plugin-detail/src/HeaderHighlight.tsx—— 门改用 helper,传field.type与objectDefField?.type两个值;resolvedType仍留给渲染器选择用。packages/plugin-detail/src/DetailSection.tsx—— 同上,替掉原来塌缩过的inlineEditType。packages/plugin-detail/src/InlineFieldInput.tsx—— 改为从fieldEnrichment导入并 re-export 集合。packages/plugin-detail/src/__tests__/inlineEditTypeNarrowing.test.tsx—— 新增 23 个用例。.changeset/detail-authored-type-narrow-only-editability.md—— patch,正文写明这是行为变更及规则本身。验证
新测试覆盖两个组件:报告者的原配置(
{ name: 'supply_share', type: 'number' }压在 rollup 上,单列一条用例)、四种计算类型的对象字段配 authorednumber、收窄仍生效(普通列上 authoredformula)、普通列对照组、以及 #3356 的readonly回归守卫。把 helper 临时改回 #3355 之前的优先级逻辑跑一遍,23 条中 13 条变红(两个组件都有),确认它们是真守卫而不是摆设。兼容性说明
任何今天依赖「用展示
type覆写把计算列变成可编辑」的页面,行为会变。issue 作者与我都构造不出这属于合理诉求而非潜在 bug 的场景 —— 这种写入要么被服务端弹回,要么落库并污染数据。需要显式表达「这个 chip 可读不可写」的场景,用 objectui#3356 落地的条目级readonly键。🤖 Generated with Claude Code
https://claude.ai/code/session_01Ehu85kbvMcrNTUJjwxvLJ9
Generated by Claude Code