Found while implementing #5727 (guarding readPrefill's seeding with isRuntimeDefault). Recording a parity gap, not a defect — after #5727 the console behaves correctly, just not as helpfully as the sibling renderer.
Measured on origin/main1939c9610.
What the sibling chain does that this one does not
@object-ui/plugin-form's schemaDefaults.ts skips runtime defaults when seeding, with ONE documented exception (#5683): current_user is resolved, not seeded literally, when the caller threads a SeedContext:
}elseif(isCurrentUserSeedField(f)&&ctx?.currentUserId){defaults[name]=ctx.currentUserId;}The argument there is that this is not a second default contract but a preview of the same one: the engine's current_user resolution is the acting user's id (applyFieldDefaults -> execCtx.userId), and the session already knows that id exactly, so seeding it and omitting it are equivalent by construction. The type gate mirrors the spec's own authoring rule (user, or lookup with reference: 'sys_user').
apps/console/src/components/FormPage.tsx's readPrefill takes no such context: after #5727 a current_user field simply opens empty on both console form routes and the server stamps the id at insert. Correct, but the operator does not see who the record will be attributed to before submitting — which is the gap #5683 closed on the other chain.
Why this is filed as an observation, not a bug
Nothing is stored wrong and nothing is suppressed; the outcome is identical, only later and invisible. It also is not free: readPrefill is a pure function taking (fields, search, record), so threading usePermissions().userId into it is a signature change on a seam this repo has been keeping narrow, and the public /f/:slug route is anonymous — there is no acting user there, which the sibling handles by seeding nothing. Whether that parity is worth the seam is a triage call.
Prior art to reuse rather than re-derive if it is taken up: isCurrentUserDefaultToken from @objectstack/spec/data and the isCurrentUserSeedField type gate in packages/plugin-form/src/schemaDefaults.ts.
Related: #5727, #5683, #4047, #4068.
Generated by Claude Code
Found while implementing #5727 (guarding
readPrefill's seeding withisRuntimeDefault). Recording a parity gap, not a defect — after #5727 the console behaves correctly, just not as helpfully as the sibling renderer.Measured on
origin/main1939c9610.What the sibling chain does that this one does not
@object-ui/plugin-form'sschemaDefaults.tsskips runtime defaults when seeding, with ONE documented exception (#5683):current_useris resolved, not seeded literally, when the caller threads aSeedContext:The argument there is that this is not a second default contract but a preview of the same one: the engine's
current_userresolution is the acting user's id (applyFieldDefaults->execCtx.userId), and the session already knows that id exactly, so seeding it and omitting it are equivalent by construction. The type gate mirrors the spec's own authoring rule (user, orlookupwithreference: 'sys_user').apps/console/src/components/FormPage.tsx'sreadPrefilltakes no such context: after #5727 acurrent_userfield simply opens empty on both console form routes and the server stamps the id at insert. Correct, but the operator does not see who the record will be attributed to before submitting — which is the gap #5683 closed on the other chain.Why this is filed as an observation, not a bug
Nothing is stored wrong and nothing is suppressed; the outcome is identical, only later and invisible. It also is not free:
readPrefillis a pure function taking(fields, search, record), so threadingusePermissions().userIdinto it is a signature change on a seam this repo has been keeping narrow, and the public/f/:slugroute is anonymous — there is no acting user there, which the sibling handles by seeding nothing. Whether that parity is worth the seam is a triage call.Prior art to reuse rather than re-derive if it is taken up:
isCurrentUserDefaultTokenfrom@objectstack/spec/dataand theisCurrentUserSeedFieldtype gate inpackages/plugin-form/src/schemaDefaults.ts.Related: #5727, #5683, #4047, #4068.
Generated by Claude Code