Repository navigation
Create form locks every field whose readonlyWhen is TRUE against the field defaults, though the server exempts INSERT from readonlyWhen #13436
Description
Filing gate: ① product defect with a reproduction (reach: console create form, measured once in the browser on 18.0.0).
Reader: objectui form renderer seat (packages/components/src/renderers/form/form.tsx, the per-field resolveFieldRuleState call), the next PR that touches create-mode rule evaluation.
Duplicate check: searched objectstack and objectui issues (open and closed) for "create form readonlyWhen evaluated on insert / fields read-only on new record": 6 + 12 hits, none about this (closest: objectui#12082, which was about permission grants, not readonlyWhen).
What happens
A field whose readonlyWhen reads a column that has a defaultValue is shown read-only on the create form, because the form evaluates the predicate against the seeded defaults. The server, by contrast, does not apply readonlyWhen on INSERT (packages/objectql/src/engine.ts, the insert-strip note: "What INSERT still does NOT strip: readonlyWhen"; objectui's own form.tsx comment says "objectql exempts INSERT from readonlyWhen entirely"). So the client is stricter than the server and the user cannot fill a form the API accepts.
Reproduction (hotsrm, platform 18.0.0)
const locked = P`record.status == 'pending_verify' || record.status == 'active'`;
status: Field.select({ defaultValue: 'pending_verify', readonly: true, options: [...] }),
bank_name: Field.text({ required: true, readonlyWhen: locked }),
account_no: Field.text({ required: true, readonlyWhen: locked }),- Open the object's list in the console and click New.
- Every field with
readonlyWhen: lockedrenders as a read-only—; the dialog has no inputs except the boolean toggle, and Create can only fail on the required fields. POST /api/v1/data/<object>with the same fields as the same user succeeds (201, the values are stored).
Same with a predicate over an unset field: readonlyWhen: P\record.approval_status != 'returned'`locks the whole create form, becausenull != 'returned'` is TRUE.
Expected
On a create form (no previousValues, the same isCreateForm signal the readonly strip already uses), readonlyWhen should not lock the field, matching the server. If locking on create is intended, the server should enforce it on INSERT too, and the spec text for Field.readonlyWhen should say so; either way client and server should agree.
Workaround in the app
Guard the predicate with has(record.id) && record.id != null && (...); the stored row on UPDATE carries id, the create form does not.
Activity
objectstack-fleet commentedon Oct 24, 2026
Claim: PM loop round 6 · 2026-10-24T09:25Z
Session:
session_01WJozybDmRH8z2c5SD7vJkj(domain:uiseat 1; an S card done by a sub-agent of this seat, dispatched by this project's coordinator)Account:
os-sales(the seat's linked user; the card's assignee)Branch:
claude/issue-13436-create-form-readonlywhenWorktree:
objectui-issue-13436Domain:
domain:uiSeat:
domain:ui#1File surface:
packages/components/src/renderers/form/form.tsx(theresolveFieldRuleStatecall sites and theisCreateFormsignal), the form renderer tests beside it inpackages/components/src/renderers/form/__tests__/(or the existing form rule-state test file), docs that describereadonlyWhenon the create form,.changeset/(one changeset) (stop on breach; explain in the report)Container & model:
S,mode:subagent(a sub-agent of this seat, baseorigin/main),model: default,effort: medium(S)Clause-②: no
Responsibility: a create form evaluates
readonlyWhenagainst seeded defaults and locks fields the server accepts on INSERT | every create dialog with areadonlyWhenfield, every user | the user cannot fill a form the API acceptsSerial constraints cleared: no open PR touches
packages/components/src/renderers/form/form.tsxorpackages/core/src/evaluator/fieldRules.ts(read in this act)objectstack-fleet commentedon Oct 24, 2026
Claim amendment ·
domain:uiseat 1 ·session_01WJozybDmRH8z2c5SD7vJkj· 2026-10-24T09:48ZFile surface, widened by two test files. Both of them assert the behaviour this card removes: a
readonlyWhenfield locking on a create form.packages/plugin-form/src/flatFieldRules.test.tsx(DrawerForm's no-sections field builder dropsvisibleWhen/readonlyWhen/requiredWhen(andgroup) — ModalForm's identical builder carries them #4755's pin). The case "locks areadonlyWhen-TRUE field" renders ModalForm and DrawerForm inmode: 'create'. DrawerForm's no-sections field builder dropsvisibleWhen/readonlyWhen/requiredWhen(andgroup) — ModalForm's identical builder carries them #4755 was about DrawerForm carrying the rules at all, and create mode was incidental there. The case moves to an edit form (mode: 'edit'with arecordId, so the container passespreviousValues). A create-mode case is added that asserts the field stays editable.e2e/live/field-conditional-rules.spec.ts(B2 live, not in the CI allowlist). Its stated premise is that the client enforces "the SAME dialect the server enforces, so the UX and the persisted verdict agree". On INSERT the server does not applyreadonlyWhen, so the step that assertstax_ratelocks on the New dialog was asserting a disagreement. That step now asserts the field stays editable on create. The PR says the spec was not run in this container.Not a fork: the card's Expected names this direction ("On a create form…
readonlyWhenshould not lock the field, matching the server"), and form.tsx's own comments already state that the server exempts INSERT. Nothing else in the claim changes. Clause-② stays no.Generated by Claude Code
objectstack-fleet commentedon Oct 24, 2026
LANDED
objectui#13436 由 PR objectui#13441 合入 main，合并提交
a78608f3803335c666d78c6d041c4ab8b0cd23f2（2026-10-24T10:30Z，经合并队列）。记录于 2026-10-24T10:35Z。Seat: domain:ui#1
落地内容：新建表单不再用 readonlyWhen 锁字段，与服务端在插入时不施加该规则保持一致；编辑表单照旧锁定，静态只读在新建时仍锁。
撤下
pm:dispatched。席位核对见 PR comment 6382990782。board archive: record 3 transferred numbers in gone.json (objectstack…
fix(components): create form no longer locks fields through readonlyW…