Skip to content

feat(templates): a field's defaultValue seeds a new line in the item dialog - #6691

Open
delchev wants to merge 1 commit into
masterfrom
feat/field-default-seeds-item-dialog
Open

feat(templates): a field's defaultValue seeds a new line in the item dialog#6691
delchev wants to merge 1 commit into
masterfrom
feat/field-default-seeds-item-dialog

Conversation

@delchev

@delchev delchev commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

What

defaultValue: on a field already reached the model — it becomes the column's DB DEFAULT and suppresses a required field's presence check — but no UI ever seeded from it. A document's item dialog built a new line out of blanks (false for a checkbox, null for a number, '' otherwise), so every authored default was invisible until the row was posted.

The visible cost is Fill Month. The guide promises it "creates an 8-hour line for every working day (Mon–Fri)", and the dialog's skip-existing-days and Mon–Fri rules do match — but Hours opened empty and Billable opened off, so the one-click promise was really type-8-toggle-billable-click.

Change

The detail registry emits the authored default as def on the column, in the shape the draft holds:

column emitted
NUMBER def: 8 (real number)
CHECKBOX def: true (real boolean)
DROPDOWN (numeric FK) def: '2' (string — the draft keeps FKs stringified so they match an option's data-value)
no default declared no key at all

openRowDialog seeds a new line from it. An existing row is untouched — re-defaulting a value the user deliberately cleared would silently undo it.

Scope

Deliberately item-dialog only. The main create form is left alone: every entity with an init: status carries a dataDefaultValue too, so seeding forms as well would visibly change create screens across the whole fleet — a separate change with its own blast radius, not something to smuggle in behind a dialog fix.

The DSL key itself needed no work — it already binds and already emits. It was, however, undocumented beyond a passing mention, so intent-assistant-guide.md now describes all three things it does.

Verification

Both templates rendered through a real Velocity engine with a NUMBER / CHECKBOX / numeric-DROPDOWN / no-default / text-default property set, confirming the table above and that the rendered registry parses as JS (node --check).

The seeding line was then simulated over new / edit / cleared rows:

  • new line takes the defaults → {Hours: 8, Billable: true, Status: '2', Note: ''}
  • edited row keeps its stored values
  • a cleared value is not re-defaulted

🤖 Generated with Claude Code

…dialog

`defaultValue:` already reached the model - it becomes the column's DB DEFAULT
and suppresses a required field's presence check - but no UI ever seeded from
it. A document's item dialog built a new line from blanks (checkbox false,
number null, else ''), so every "default" was invisible until the row was
posted.

The visible cost: Fill Month. The guide promises it "creates an 8-hour line for
every working day", and the dialog's skip-existing-days and Mon-Fri rules do
match - but Hours opened empty and Billable opened off, so the one-click promise
was really type-8-toggle-billable-click.

The registry now emits the authored default as `def` on the column, in the shape
the draft holds: a checkbox gets a real boolean, a numeric column a real number,
and everything else a string - including a DROPDOWN's FK, which the draft keeps
stringified so it matches an option's data-value. openRowDialog seeds a NEW line
from it. An EXISTING row is untouched: re-defaulting a value the user
deliberately cleared would silently undo it.

Deliberately item-dialog only. The main create form is left alone: every entity
with an `init:` status carries a dataDefaultValue too, so seeding forms as well
would visibly change create screens across the whole fleet - a separate change
with its own blast radius, not something to smuggle in behind a dialog fix.

Verified by rendering both templates through a real Velocity engine: a NUMBER
default emits `def: 8`, a CHECKBOX `def: true`, a numeric DROPDOWN FK `def: '2'`,
and a column without a default emits no key at all; the rendered registry parses
as JS. The seeding line was then simulated over new/edit/cleared rows - a new
line takes the defaults, an edited row keeps its stored values, and a cleared
value is not re-defaulted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant