@dforge-core/metadata 0.0.12 → 0.0.14

package/CHANGELOG.md

@@ -5,6 +5,66 @@ All notable changes to `@dforge-core/metadata` are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this package adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.0.14] — 2026-08-10
+
+### Added
+
+- **A report parameter can borrow a column domain.** `paramDef` accepts `domain`
+  (`domain_cd` or `module_cd.domain_cd`) as an alternative to `fieldTypeCd`: the domain
+  supplies the control *and* the option list, so a list shared with the column the
+  parameter's value is written to is authored — and translated — exactly once instead of
+  being restated per parameter and left to drift. The action-DSL equivalent is
+  `paramCd: domain <domainCd>`, which has no JSON schema of its own.
+
+  `schemas/reports.schema.json` rejects exactly one combination —
+  `not: { required: ["fieldTypeCd", "domain"] }` — so declaring both is invalid, matching
+  the install-time check that refuses to silently pick a winner. Declaring neither stays
+  valid: the param installs as `text`.
+
+### Changed
+
+- **`ParamDef` is now a union, and `fieldTypeCd` is no longer required.** The type mirrors
+  the schema: one branch carries an optional `fieldTypeCd` (with `domain?: never`), the
+  other requires `domain` (with `fieldTypeCd?: never`). The shared members moved to an
+  exported `ParamDefBase`.
+
+  **Breaking for TypeScript consumers** in two ways, both intentional: a param literal
+  declaring both keys no longer compiles, and reading `p.fieldTypeCd` off a `ParamDef`
+  now yields `string | undefined` — a domain-backed param genuinely doesn't carry one,
+  and an inline param may omit it and take the `text` default. This is the
+  authoring-manifest type (what you write in `ui/reports.json`); the SDK's runtime
+  `ReportParamDef` is unchanged, since the server resolves the domain at install and the
+  wire payload always carries a concrete `fieldTypeCd` plus the merged option list.
+
+- **`params.options` documentation.** The doc comment now spells out that a dropdown
+  param's options take the same rich `{value, label, icon, color}` form entity columns
+  use, and that a bare string list renders raw codes in every locale — which is what
+  action and report parameters did until dForge-core 1.20.0 gave them a place to put a
+  label. Per-locale option labels live in `translations/<locale>.json` under
+  `reports.<report_cd>.params.<param_cd>.options`.
+
+## [0.0.13] — 2026-08-07
+
+### Changed
+
+- **Filter operators are now a closed, enumerated set.** `FilterCondition.o` and
+  `FilterGroup.g` were typed as plain `string`, and the `o` field in
+  `schemas/{data_views,reports,folders}.schema.json` had no `enum` — its description
+  listed operators that never existed (`isNull`, `isNotNull`, `neq`, `gt`, `gte`,
+  `lt`, `lte`, `like`). Modules were authored against that list; the server drops an
+  operator it can't translate, so those conditions were silently discarded at query
+  time and the query ran *wider* than written. The schemas now carry an `enum`, and
+  the TS types narrow to the new `FilterOperator` / `FilterGroupOperator` unions,
+  exported alongside the `FILTER_OPERATORS` / `FILTER_GROUP_OPERATORS` value arrays.
+
+  The real spellings for the ones most often invented: `null` / `!null` (not
+  `isNull` / `isNotNull`), `contains` or `mask` (not `like`), and
+  `!=` / `>` / `>=` / `<` / `<=` (not `neq` / `gt` / `gte` / `lt` / `lte`).
+
+  **Breaking for TypeScript consumers** that assign an arbitrary `string` to `o` or
+  `g` — those assignments now fail to compile, which is the point: dForge-core
+  rejects the same values at module install.
+
 ## [0.0.12] — 2026-08-04
 
 ### Changed