proposal: what a copy does not carry over

[delchev]

duplicable: true is a bare boolean. The Duplicate it adds clones the source header verbatim - minus the values no user authored - so every ordinary user field rides along, including the ones a business rule says must be fresh. On a sales invoice that is the three dates: "same invoice as last month" opens as a draft dated last month, due last month, with last month's tax event, and an unnoticed tax-event date is a legally wrong document.

The model cannot say otherwise on its own side: a calculatedActionOnCreate fills an empty value and respects a present one - the right contract for a hand-made invoice, and exactly what makes the copied value stick - and a plain required date carries no rule at all.

Proposes the object form, reusing the vocabulary generates: already has:

- name: SalesInvoice
  duplicable:
    defaults: { date: now }        # constants written into the clone
    reset: [due, taxEventDate]     # dropped, so the entity's own create-time rule refills them

Two keywords rather than defaults: { due: null }: reset says what actually happens - the value is handed back to the entity's create-time rule instead of being assigned - and the two compose, reset for a field that HAS such a rule, defaults for one that does not. duplicable: true stays the shorthand and generates byte-identically.

The proposal carries the Specification text (anchored after Entities > Control order), its two normative blocks including the local-calendar rule for now, and the Appendix A row. The implicit alternative - dropping every calculatedActionOnCreate field on duplicate, with no authoring change - is recorded as considered and rejected as a default, since it would also recompute fields the source deliberately overrode.

Implemented in eclipse-dirigible#7360; docs in dirigible-io.github.io#245.

🤖 Generated with Claude Code