`highlightFields` cannot declare read-only, so the detail page's header chips let users overwrite hook-maintained columns

[yinlianghui]

Summary

The header chip strip on a record detail page is built from the object's highlightFields. Those chips are inline-editable and the edits save. There is no way to declare a highlight field read-only, so columns that are exclusively maintained by hooks can be overwritten by anyone who clicks on them.

Why there is no authoring knob

highlightFields: z.ZodOptional<z.ZodArray<z.ZodString>>;
// → highlightFields?: string[] | undefined

A plain array of field names. No per-field options at all — no readonly, no disabled, nothing.

The three things an app can reach for, and why each fails

1. View-level readonly on the form view's section fields. This works, but only for the form/dialog render path. The detail page's header chips are a different surface and do not consult it. That asymmetry is the reported symptom: the create/edit dialog refuses the edit while the detail page accepts it.

2. readonly: true on the object field. stripReadonlyFields drops caller-supplied readonly keys for any non-isSystem context. Our columns are written by cross-object hooks, which inherit the acting user's non-isSystem context, so marking them readonly makes the hook's writes silently vanish and the columns never update again.

3. Field-level editable: false in a permission set. getFieldPermissions has no super-user bypass — modifyAllRecords does not apply at field level, and field-level entries take precedence over the object-level decision. plugin-security's detectForbiddenWrites then throws 403 for non-isSystem writes, which kills the same hook write-back. Turning it off for the admin turns it off for the hook.

So an app that has hook-maintained columns and wants them on the header strip has no legal way to protect them.

Reproduce

1. Declare a column written only by an afterInsert/afterUpdate hook on another object.
2. Put it in highlightFields, and mark it readonly on the form view's section field.
3. Open the record detail page. The header chip for that column is editable; changing it and saving persists the value, overwriting what the hook computed. The create/edit dialog for the same record refuses the same edit.

Impact

For us these are derived business figures — a customer grade written back by a rating approval, and a supply-share percentage rolled up from two child objects. A user clicking a chip silently replaces a computed value with a typed one, with no indication that the column is machine-owned.

A readonly flag on highlightFields entries — or having the header chips honour the form view's field-level readonly — would close this.

Environment

@objectstack/* protocol ^17.0.0-rc.1, console from @objectstack/console, driver-sql on SQLite.

Filed from a downstream app (hotcrm-heimao), tracked there as issue #61.

[yinlianghui]

Correction + browser-measured reproduction

I re-ran this in a real browser rather than from the type definitions, and the conclusion holds — an app has no way to protect these columns — but two statements in the description are wrong in a way that makes the fix look bigger than it is. Corrected below.

Measured reproduction

Fresh database, @objectstack/console 17.0.0-rc.1, Chromium 1194, locale zh-CN, admin user.

Double-clicking a header chip puts the whole strip into inline-edit mode with a save bar. Typing a value and clicking save:

PATCH /api/v1/data/crm_account/6z6fxcQb0h5lmh-c
body   {"supply_share":99}
→ 200

After a full page reload the chip shows 99. Read back over REST:

{ "share": 99, "our": 6000, "comp": 15000 }

supply_share is defined as our / (our + competitor) × 100, so the correct value is 28.57. The three columns no longer reconcile, and nothing self-heals. The rollup only re-fires when a child row changes — touching one child row afterwards restored 28.57, but until someone does that, the fabricated number stays on screen and in the database indefinitely.

❌ Correction 1 — there is a per-field config path; it just has no readonly

The description says highlight entries are "a plain array of field names. No per-field options at all". That is true of the object's highlightFields, but not of the surface that actually renders them. The record:highlights page component normalizes each properties.fields[] entry:

(Array.isArray(schema.fields) ? schema.fields : []).map(e =>
  typeof e === 'string' ? { name: e } : { name: e?.name, label: e?.label, icon: e?.icon, type: e?.type })

So an object entry is accepted, and type demonstrably takes effect — we ship one today to work around #5066:

properties: { fields: [ …, { name: 'supply_share', type: 'number' }, … ] }

That override changes which display renderer the chip picks (verified on screen). So the authoring path exists.

❌ Correction 2 — the chip already checks readonly; the renderer drops the key

This is the actionable part. The chip's own editability test reads:

const isNonEditableType = NON_EDITABLE_TYPES.has(type);
const isReadonly = entry.readonly === true || schemaField?.readonly === true;
const canInlineEdit = canEdit && !isNonEditableType && !isReadonly && !ALWAYS_LOCKED.has(entry.name);

entry.readonly is already consulted. But the normalize map above copies only {name, label, icon, type} — readonly is dropped one layer before the check that would honour it. The check can therefore never fire from authored metadata; only schemaField.readonly can, and that is the route the description correctly rules out (stripReadonlyFields kills the cross-object hook writes, #2948).

So this is not a spec change to highlightFields. Adding readonly: e?.readonly to that one normalize map makes the existing check reachable.

What I measured that does not work (so nobody re-tries these)

All tested on a live page, reading the rendered DOM for the cursor-pointer / 双击编辑 inline-edit affordance:

authored in the record:highlights slot	chip still inline-editable?
{ name: 'supply_share', readonly: true }	yes — readonly is dropped in normalization
{ name: 'current_total_score', readonly: true }	yes
{ name: 'supply_share', type: 'formula' }	yes
{ name: 'last_year_volume', type: 'summary' }	yes
{ name: 'last_year_volume', type: 'rollup' }	yes

The last three are worth flagging separately: NON_EDITABLE_TYPES contains formula / summary / rollup / auto_number, so an authored type of any of those looks like it should trip isNonEditableType — and it does not. Whatever resolves the effective type for that gate is not reading the authored entry, even though the same authored type does reach the display-renderer selection. Two consumers of one field, disagreeing. Worth fixing alongside the dropped readonly.

redactFields and enforceFieldSecurity on the same component were also considered: both remove the chip rather than lock it, which is not what is wanted for a value whose whole point is being displayed.

Suggested fix, smallest first

1. Copy readonly through the record:highlights entry normalization — one key, makes the existing check reachable, unblocks every downstream app immediately.
2. Make the editability gate read the same effective type the renderer selection reads, so an authored type: 'formula' is honoured consistently.
3. Longer term: have the header chips consult the form view's field-level readonly, so one declaration covers both surfaces and the dialog/detail-page asymmetry that produced this report disappears.

Downstream tracking: yinlianghui/hotcrm-heimao#61.

---

Generated by Claude Code

[xuyushun441-sys]

CLAIM

• 会话:session_01Ehu85kbvMcrNTUJjwxvLJ9(spec 车道 PM,派发给 os-dev 实施)
• 分支:objectui 仓 claude/issue-5077-highlights-readonly
• 前提以 2026-08-04 浏览器实测评论为准:非 spec 变更 —— record:highlights 组件的归一化表把 readonly 键在既有检查之前丢掉了,且可编辑性门读的有效 type 与渲染器选择不一致。范围 = 实测评论的建议 1 + 2;建议 3(贯通表单视图 field-level readonly)不在本单。

---

Generated by Claude Code

[xuyushun441-sys]

结案(2026-08-04)

按维护者定调「按 bug 修,协议零改动」,两半修复均已合入 objectui main:

1. objectui#3356 —— record:highlights 归一化表补传 readonly,授权 {name, readonly: true} 的 chip 从此锁定 inline 编辑(本单标题症状);
2. objectui#3357 —— 可编辑性门改「只收窄」:authored 显示 type 永远不能放宽门 —— 对象字段是 formula/summary/rollup/auto_number 时,无论条目写什么 type,chip 都锁死。这是报告方实际上线配置(rollup 上写 type:'number' 绕 Console: percent display renderer's fixed-width progress bar clips the value in a record-highlights chip (33% renders as 3) #5066)触发腐蚀的真实路径;HeaderHighlight 与 DetailSection 两站点共享同一 helper(fieldEnrichment),防 drift。

协议未动:highlightFields 仍是纯字符串数组,RecordHighlightsField 词表不变。readonly 进 spec 词表的事(#5176)已登记为 #5068(SDUI props 闸门)的硬前置,不单独排期 —— 将来谁开闸门,谁必须先落声明,防止本单症状以零诊断形态复发。

@yinlianghui 下游 hotcrm-heimao#61:两个修复随下一个 console 发布可验;你们现有的 type:'number' workaround 无需回退(#3357 后它只影响显示渲染,不再打开编辑)。

---

Generated by Claude Code