intent: duplicable defaults take now on a timestamp field (#7396) - #7423
Merged
Merged
Conversation
`IntentParser.validateDuplicableDefault` accepted `now` on a date / month / week
field and refused everything else, so
duplicable:
defaults: { recordedAt: now } # recordedAt is `type: timestamp`
failed validation with "that property is not a date" - although a timestamp
property holds exactly the kind of value `now` means. `date` and `timestamp`
differ only in precision, and the copy of a document is made now in both cases,
so the refusal ruled out the one value an author would write there and left a
`calculatedActionOnCreate` class, or a clone carrying the source's timestamp, as
the only ways to say it.
The sibling of #7392 on the duplicable path, and one rendering step further than
it, because this half renders in JavaScript rather than Java:
- `validateDuplicableDefault` reads the accepted types from a named set, so a
temporal type added later is one line and not another `equals` chain;
- `EdmIntentGenerator.duplicateDefaults` emits the AUTHORED shape instead of
collapsing everything that is not month/week to `date`;
- `todayAs` in `document-page.js.template` renders a `timestamp` as the ISO
instant - the same conversion the form's own `toPayload()` already does for a
datetime input, since a `java.time.Instant` property does not bind the local
calendar shapes the other kinds send. The calendar shapes stay built from the
LOCAL fields: east of Greenwich `toISOString()` dates an evening copy
yesterday, which is why the timestamp shape is the deliberate exception and
not a relaxation of that rule.
A model that declares no timestamp default generates byte-identically.
Verified: `DuplicableIntentTest` accepts `now` on a timestamp field and still
refuses it on a string and on a to-one relation (whose default assigns a raw
foreign key), 20 tests green; `EdmIntentGeneratorTest` asserts the emitted
`shape: timestamp` next to the unchanged date / month / literal entries; the
engine-intent unit suite is green (1327 tests); `IntentEmissionCoverageIT` now
carries a `timestamp` field on `Reorder` with a `now` default and asserts both
the generated `todayAs('timestamp')` assignment and the helper's instant branch
in the published document page - green, and the module it publishes compiles.
Not run: the full IT suite, and no browser pass on a real Duplicate click.
Fixes #7396
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
IntentParser.validateDuplicableDefaultacceptednowon a date / month / weekfield and refused everything else, so
failed validation with "that property is not a date" - although a timestamp
property holds exactly the kind of value
nowmeans.dateandtimestampdiffer only in precision, and the copy of a document is made now in both cases,
so the refusal ruled out the one value an author would write there and left a
calculatedActionOnCreateclass, or a clone carrying the source's timestamp, asthe only ways to say it.
The sibling of #7392 on the duplicable path, and one rendering step further than
it, because this half renders in JavaScript rather than Java:
validateDuplicableDefaultreads the accepted types from a named set, so atemporal type added later is one line and not another
equalschain;EdmIntentGenerator.duplicateDefaultsemits the AUTHORED shape instead ofcollapsing everything that is not month/week to
date;todayAsindocument-page.js.templaterenders atimestampas the ISOinstant - the same conversion the form's own
toPayload()already does for adatetime input, since a
java.time.Instantproperty does not bind the localcalendar shapes the other kinds send. The calendar shapes stay built from the
LOCAL fields: east of Greenwich
toISOString()dates an evening copyyesterday, which is why the timestamp shape is the deliberate exception and
not a relaxation of that rule.
A model that declares no timestamp default generates byte-identically.
Verified:
DuplicableIntentTestacceptsnowon a timestamp field and stillrefuses it on a string and on a to-one relation (whose default assigns a raw
foreign key), 20 tests green;
EdmIntentGeneratorTestasserts the emittedshape: timestampnext to the unchanged date / month / literal entries; theengine-intent unit suite is green (1327 tests);
IntentEmissionCoverageITnowcarries a
timestampfield onReorderwith anowdefault and asserts boththe generated
todayAs('timestamp')assignment and the helper's instant branchin the published document page - green, and the module it publishes compiles.
Not run: the full IT suite, and no browser pass on a real Duplicate click.
Fixes #7396
🤖 Generated with Claude Code