@object-ui/core 17.3.0 → 17.6.0

package/dist/utils/expand-fields.d.ts

@@ -11,17 +11,107 @@
  * list / grid / detail cell can render the related record's display name
  * instead of a bare id placeholder ("—").
  *
- * This mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
- * (`lookup` / `master_detail` / `tree`) and additionally covers `user` — a
- * lookup specialised to `sys_user`. The server resolves `user` through the
- * same expand path as `lookup` / `master_detail` (it carries the same
- * `reference` + id storage), so a `user` column that is NOT requested for
- * expansion comes back as a raw user id and renders as "—". Keeping the set
- * here as the single source of truth is what closes that gap.
+ * `user` is a lookup specialised to `sys_user`: it carries the same `reference`
+ * + id storage and the server resolves it through the same expand path as
+ * `lookup` / `master_detail`, so a `user` column that is NOT requested for
+ * expansion comes back as a raw user id and renders as "—" (objectui#2032).
  *
  * Note on `tree`: a self-referencing hierarchy field is a reference too, so it
  * belongs in this set; whether the backend materialises the expanded object
  * for it is a server concern — requesting it is harmless and forward-compatible.
+ *
+ * ## One family, many consumers — and NO reliable count of them
+ *
+ * This section used to open "One family, four consumers" and enumerate four.
+ * That count was hand-kept, and hand-kept counts of this table are exactly what
+ * keeps going wrong: it was already stale by two when objectui#5692 measured it
+ * (`paramToField` in `app-shell` had joined with objectui#5312, and
+ * `ListView`'s relational-sort rule reads the set directly), and objectui#5312's
+ * claim to have converted "the LAST private copy" was false by two MORE — see
+ * the falsification note at the end. Read the list below as the lineage of the
+ * conversions, not as a census; the mechanical fact is the identity pins.
+ *
+ * This is the reference-bearing FAMILY, not the `$expand` builder's private
+ * list, and these concerns read it under several different words:
+ *
+ *  - `$expand` construction — `buildExpandFields` below ("expandable");
+ *  - predicate-record projection — `predicate-record.ts` ("relational");
+ *  - the object form's data-source wiring — `needsDataSourceWiring` in
+ *    `packages/components/src/renderers/form/form.tsx`, which decides which
+ *    registered widget gets `dataSource` / `dependentValues` /
+ *    `dependsOnLabels` threaded to it;
+ *  - the grid's bulk-action dialog — `widgetNeedsDataSource` in
+ *    `packages/plugin-grid/src/components/bulkParamToField.ts`, which decides
+ *    which param widget is handed the grid's `DataSource` and which param field
+ *    shape carries `reference_to` / `display_field`;
+ *  - the action-param dialog — `paramToField` in
+ *    `packages/app-shell/src/utils/paramToField.ts`, which decides which param
+ *    carries a reference target (objectui#5312);
+ *  - the list view's relational-sort rule — `ListView.tsx`, which will not offer
+ *    a server-side sort on a field whose stored value is a foreign key;
+ *  - the dashboard table's `$expand` whitelist — `computeLookupExpand` in
+ *    `packages/plugin-dashboard/src/ObjectDataTable.tsx` (objectui#5692);
+ *  - the dashboard's relation/link test — `isLookupType` in
+ *    `packages/plugin-dashboard/src/recordFields.tsx` (objectui#5692).
+ *
+ * The third one used to be a second hand-maintained copy, and this comment used
+ * to claim the set "mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
+ * (`lookup` / `master_detail` / `tree`)". That was true for 15 days. The form's
+ * copy then gained `capability-multiselect` (objectui#2403) and, the same day,
+ * `object-ref` / `filter-condition` / `recipient-picker` (objectui#2421), after
+ * which the two sets were not in a subset relation in EITHER direction — `user`
+ * only here, three picker names only there — and no gate could say so
+ * (objectui#4790). The form now DERIVES from this set instead of restating it:
+ *
+ *     form's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *                                  + three widget-hint-only picker names
+ *
+ * The extension is one-directional and cannot fold back into this set:
+ * `object-ref` / `filter-condition` / `recipient-picker` are widget HINTS, never
+ * declarable field types (`widgetHintOnly: true` in
+ * `app-shell/src/utils/paramValueShape.ts`), so no object schema can produce a
+ * field whose `type` is one of them.
+ *
+ * The fourth was a hand-maintained copy too, one member set removed from BOTH
+ * of the above (`lookup` / `master_detail` / `user` — no `tree`, no pickers, and
+ * for a while a fifth spelling, `owner`, that objectui#4814 retired). It now
+ * derives from this set with NO extension, because the bulk dialog's params
+ * cannot produce the three widget-hint names (objectui#4815):
+ *
+ *     bulk dialog's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *
+ * Neither consumer copies the set — both call `.has()` on THIS object, and both
+ * carry an identity pin (a spy on this `has`) so a member-identical private copy
+ * fails rather than quietly re-forking the table.
+ *
+ * ## The "LAST private copy" claim was false — objectui#5692
+ *
+ * objectui#5312 converted `paramToField` (`app-shell`) and recorded it as the
+ * fourth and LAST private copy of this rule. `packages/plugin-dashboard` held
+ * two more the whole time — `LOOKUP_TYPES` in `recordFields.tsx` and an inline
+ * disjunction inside `computeLookupExpand` in `ObjectDataTable.tsx` — which
+ * predate that sweep and were outside its file surface, so nothing contradicted
+ * the claim. Both now derive from this set with NO extension and carry the same
+ * identity pin.
+ *
+ * Those two were NOT member-identical to this set, in either direction: they
+ * lacked `tree` and carried a fifth spelling, `reference`. Converging them was
+ * therefore a behaviour change in two directions, and the direction that could
+ * have widened THIS set was settled by measurement rather than by preference:
+ * `reference` is absent from `@objectstack/spec`'s closed `FieldType`
+ * vocabulary and is refused by `FieldSchema.safeParse` — measured with `lookup`
+ * / `master_detail` / `user` / `tree` as live controls and the retired `owner`
+ * plus a nonsense spelling as dead ones — so no spec-compliant object schema can
+ * declare a field whose stored type is `reference`, and the dashboard's copies
+ * were carrying a dead spelling, not a member this set was missing. This set is
+ * unchanged by objectui#5692; the two dashboard faces simply stopped answering
+ * for a type no producer can emit.
+ *
+ * Stated so it reads as a decision rather than a surprise: **adding a member
+ * here also grants that type the form's data-source wiring.** That is the
+ * intended coupling — a type whose stored value is a foreign key needs a
+ * `DataSource` to resolve that key on the read path (expand) and on the edit
+ * path (the picker) alike.
  */
 export declare const EXPANDABLE_FIELD_TYPES: ReadonlySet<string>;
 /**

package/dist/utils/expand-fields.js

@@ -12,17 +12,107 @@ import { columnIdentity } from './column-identity.js';
  * list / grid / detail cell can render the related record's display name
  * instead of a bare id placeholder ("—").
  *
- * This mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
- * (`lookup` / `master_detail` / `tree`) and additionally covers `user` — a
- * lookup specialised to `sys_user`. The server resolves `user` through the
- * same expand path as `lookup` / `master_detail` (it carries the same
- * `reference` + id storage), so a `user` column that is NOT requested for
- * expansion comes back as a raw user id and renders as "—". Keeping the set
- * here as the single source of truth is what closes that gap.
+ * `user` is a lookup specialised to `sys_user`: it carries the same `reference`
+ * + id storage and the server resolves it through the same expand path as
+ * `lookup` / `master_detail`, so a `user` column that is NOT requested for
+ * expansion comes back as a raw user id and renders as "—" (objectui#2032).
  *
  * Note on `tree`: a self-referencing hierarchy field is a reference too, so it
  * belongs in this set; whether the backend materialises the expanded object
  * for it is a server concern — requesting it is harmless and forward-compatible.
+ *
+ * ## One family, many consumers — and NO reliable count of them
+ *
+ * This section used to open "One family, four consumers" and enumerate four.
+ * That count was hand-kept, and hand-kept counts of this table are exactly what
+ * keeps going wrong: it was already stale by two when objectui#5692 measured it
+ * (`paramToField` in `app-shell` had joined with objectui#5312, and
+ * `ListView`'s relational-sort rule reads the set directly), and objectui#5312's
+ * claim to have converted "the LAST private copy" was false by two MORE — see
+ * the falsification note at the end. Read the list below as the lineage of the
+ * conversions, not as a census; the mechanical fact is the identity pins.
+ *
+ * This is the reference-bearing FAMILY, not the `$expand` builder's private
+ * list, and these concerns read it under several different words:
+ *
+ *  - `$expand` construction — `buildExpandFields` below ("expandable");
+ *  - predicate-record projection — `predicate-record.ts` ("relational");
+ *  - the object form's data-source wiring — `needsDataSourceWiring` in
+ *    `packages/components/src/renderers/form/form.tsx`, which decides which
+ *    registered widget gets `dataSource` / `dependentValues` /
+ *    `dependsOnLabels` threaded to it;
+ *  - the grid's bulk-action dialog — `widgetNeedsDataSource` in
+ *    `packages/plugin-grid/src/components/bulkParamToField.ts`, which decides
+ *    which param widget is handed the grid's `DataSource` and which param field
+ *    shape carries `reference_to` / `display_field`;
+ *  - the action-param dialog — `paramToField` in
+ *    `packages/app-shell/src/utils/paramToField.ts`, which decides which param
+ *    carries a reference target (objectui#5312);
+ *  - the list view's relational-sort rule — `ListView.tsx`, which will not offer
+ *    a server-side sort on a field whose stored value is a foreign key;
+ *  - the dashboard table's `$expand` whitelist — `computeLookupExpand` in
+ *    `packages/plugin-dashboard/src/ObjectDataTable.tsx` (objectui#5692);
+ *  - the dashboard's relation/link test — `isLookupType` in
+ *    `packages/plugin-dashboard/src/recordFields.tsx` (objectui#5692).
+ *
+ * The third one used to be a second hand-maintained copy, and this comment used
+ * to claim the set "mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
+ * (`lookup` / `master_detail` / `tree`)". That was true for 15 days. The form's
+ * copy then gained `capability-multiselect` (objectui#2403) and, the same day,
+ * `object-ref` / `filter-condition` / `recipient-picker` (objectui#2421), after
+ * which the two sets were not in a subset relation in EITHER direction — `user`
+ * only here, three picker names only there — and no gate could say so
+ * (objectui#4790). The form now DERIVES from this set instead of restating it:
+ *
+ *     form's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *                                  + three widget-hint-only picker names
+ *
+ * The extension is one-directional and cannot fold back into this set:
+ * `object-ref` / `filter-condition` / `recipient-picker` are widget HINTS, never
+ * declarable field types (`widgetHintOnly: true` in
+ * `app-shell/src/utils/paramValueShape.ts`), so no object schema can produce a
+ * field whose `type` is one of them.
+ *
+ * The fourth was a hand-maintained copy too, one member set removed from BOTH
+ * of the above (`lookup` / `master_detail` / `user` — no `tree`, no pickers, and
+ * for a while a fifth spelling, `owner`, that objectui#4814 retired). It now
+ * derives from this set with NO extension, because the bulk dialog's params
+ * cannot produce the three widget-hint names (objectui#4815):
+ *
+ *     bulk dialog's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *
+ * Neither consumer copies the set — both call `.has()` on THIS object, and both
+ * carry an identity pin (a spy on this `has`) so a member-identical private copy
+ * fails rather than quietly re-forking the table.
+ *
+ * ## The "LAST private copy" claim was false — objectui#5692
+ *
+ * objectui#5312 converted `paramToField` (`app-shell`) and recorded it as the
+ * fourth and LAST private copy of this rule. `packages/plugin-dashboard` held
+ * two more the whole time — `LOOKUP_TYPES` in `recordFields.tsx` and an inline
+ * disjunction inside `computeLookupExpand` in `ObjectDataTable.tsx` — which
+ * predate that sweep and were outside its file surface, so nothing contradicted
+ * the claim. Both now derive from this set with NO extension and carry the same
+ * identity pin.
+ *
+ * Those two were NOT member-identical to this set, in either direction: they
+ * lacked `tree` and carried a fifth spelling, `reference`. Converging them was
+ * therefore a behaviour change in two directions, and the direction that could
+ * have widened THIS set was settled by measurement rather than by preference:
+ * `reference` is absent from `@objectstack/spec`'s closed `FieldType`
+ * vocabulary and is refused by `FieldSchema.safeParse` — measured with `lookup`
+ * / `master_detail` / `user` / `tree` as live controls and the retired `owner`
+ * plus a nonsense spelling as dead ones — so no spec-compliant object schema can
+ * declare a field whose stored type is `reference`, and the dashboard's copies
+ * were carrying a dead spelling, not a member this set was missing. This set is
+ * unchanged by objectui#5692; the two dashboard faces simply stopped answering
+ * for a type no producer can emit.
+ *
+ * Stated so it reads as a decision rather than a surprise: **adding a member
+ * here also grants that type the form's data-source wiring.** That is the
+ * intended coupling — a type whose stored value is a foreign key needs a
+ * `DataSource` to resolve that key on the read path (expand) and on the edit
+ * path (the picker) alike.
  */
 export const EXPANDABLE_FIELD_TYPES = new Set([
     'lookup',

package/dist/utils/filter-tokens.js

@@ -116,7 +116,6 @@ export function resolveContextTokens(filter, scope = {}) {
         ? () => { }
         : scope.onUnresolved ??
             ((message) => {
-                // eslint-disable-next-line no-console
                 console.warn(`[object-ui] ${message}`);
             });
     const values = {

package/dist/utils/freeze-schema.d.ts

@@ -36,6 +36,33 @@ export declare const SYSTEM_VIEW_MARKER: unique symbol;
 export type DeepReadonly<T> = T extends (...args: any[]) => any ? T : T extends ReadonlyArray<infer U> ? ReadonlyArray<DeepReadonly<U>> : T extends object ? {
     readonly [K in keyof T]: DeepReadonly<T[K]>;
 } : T;
+/**
+ * The inverse of `DeepReadonly<T>`: recursively strip `readonly` at every depth.
+ *
+ * Named `DeepMutable` rather than `Mutable` for the same reason the type above
+ * is not called `Readonly` — TS' built-in `Readonly<T>` is SHALLOW, so a bare
+ * `Mutable` would understate what this does by exactly the depth gap that made
+ * `cloneAsOverride` wrong in the first place. A type whose name misreports its
+ * own reach is the defect this pair exists to close, not a naming preference.
+ *
+ * Symmetric with `DeepReadonly` arm for arm, deliberately including its two
+ * limits: a tuple widens to an array (`DeepReadonly` widens it the same way, so
+ * an inverse that preserved tuples would not be an inverse), and `Date`,
+ * `RegExp`, `Map` and `Set` are mapped as plain objects even though
+ * `isFreezableObject` skips them at runtime.
+ *
+ * One thing it deliberately does NOT do: drop the `SYSTEM_VIEW_MARKER` key.
+ * `cloneAsOverride` never copies the symbol, so a clone's marker is always
+ * absent — but the key is declared optional (`?: true`), and carrying it
+ * therefore states "may be absent", which is true. Excluding it needs
+ * `Exclude<keyof T, typeof SYSTEM_VIEW_MARKER>`, a NON-homomorphic mapped type
+ * that drops the `?` modifier from every other property and turns optional keys
+ * required — a strictly worse type, and a real break for callers, traded for
+ * removing a key that already reads as optional.
+ */
+export type DeepMutable<T> = T extends (...args: any[]) => any ? T : T extends ReadonlyArray<infer U> ? DeepMutable<U>[] : T extends object ? {
+    -readonly [K in keyof T]: DeepMutable<T[K]>;
+} : T;
 /**
  * A schema that has been frozen by `defineSystemView()`. The marker symbol is
  * non-enumerable and therefore invisible to consumers, but its presence
@@ -87,8 +114,18 @@ export declare function isSystemView(value: unknown): boolean;
  * Produce a deep, mutable clone of a System View so callers can apply
  * Tenant/User overrides without touching the source schema.
  *
+ * Returns `DeepMutable<T>`, not `T`. The declaration used to hand back the
+ * input type unchanged, which meant cloning a `SystemView<S>` returned
+ * something still typed deep-readonly even though the implementation had always
+ * produced a plain mutable object — so the override flow this function exists
+ * for, `draft.columns.push(...)`, did not type-check (TS2339). The return type
+ * now relaxes TOWARD what the runtime already does, never away from it, which
+ * is why the change adds capability to a caller's type rather than removing it.
+ *
  * Implementation note: uses `structuredClone` when available (Node 17+, all
  * evergreen browsers) and falls back to a JSON round-trip. The marker
  * symbol is intentionally NOT copied — the clone is no longer a System View.
+ * Neither path can copy it by accident: `structuredClone` ignores symbol keys,
+ * and `JSON.stringify` never sees them.
  */
-export declare function cloneAsOverride<T>(view: T): T;
+export declare function cloneAsOverride<T>(view: T): DeepMutable<T>;

package/dist/utils/freeze-schema.js

@@ -140,9 +140,19 @@ export function isSystemView(value) {
  * Produce a deep, mutable clone of a System View so callers can apply
  * Tenant/User overrides without touching the source schema.
  *
+ * Returns `DeepMutable<T>`, not `T`. The declaration used to hand back the
+ * input type unchanged, which meant cloning a `SystemView<S>` returned
+ * something still typed deep-readonly even though the implementation had always
+ * produced a plain mutable object — so the override flow this function exists
+ * for, `draft.columns.push(...)`, did not type-check (TS2339). The return type
+ * now relaxes TOWARD what the runtime already does, never away from it, which
+ * is why the change adds capability to a caller's type rather than removing it.
+ *
  * Implementation note: uses `structuredClone` when available (Node 17+, all
  * evergreen browsers) and falls back to a JSON round-trip. The marker
  * symbol is intentionally NOT copied — the clone is no longer a System View.
+ * Neither path can copy it by accident: `structuredClone` ignores symbol keys,
+ * and `JSON.stringify` never sees them.
  */
 export function cloneAsOverride(view) {
     if (view == null || typeof view !== 'object')

package/dist/utils/humanize-label.d.ts

@@ -0,0 +1,60 @@
+/**
+ * ObjectUI — value-fallback label prettifier
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/**
+ * humanize-label — the ONE home for the VALUE fallback: a stored value becomes
+ * a display string when nothing else resolves it (objectui#5444).
+ *
+ * Two byte-identical copies preceded this module: `@object-ui/fields` (read by
+ * `plugin-grid`, `plugin-gantt`, `plugin-detail`, and by the field renderers in
+ * that package itself) and a deliberate local copy in `plugin-charts`'
+ * `ObjectChart.tsx`, whose comment said it existed "to avoid a dependency on
+ * `@object-ui/fields`". `@object-ui/core` is the shared ancestor both packages
+ * already depend on, so the convention gets a single home without a new
+ * dependency edge and without React reaching core — objectui#4389's ruling for
+ * this family: core-canonical logic, plugins consume; never core importing
+ * react. Both former sites now re-export THIS function, so there is one
+ * implementation and two doorways.
+ *
+ * ## Why this is NOT `humanizeFieldKey`, and why the two are kept apart
+ *
+ * The renderer carries a second prettifier — `humanizeFieldKey` in
+ * `@object-ui/plugin-dashboard`, the single home for the KEY fallback (a field
+ * key becomes a column header). It is a DIFFERENT convention, not a stale copy
+ * of this one: it additionally splits camelCase.
+ *
+ *   input                humanizeFieldKey     humanizeLabel (here)
+ *   ──────────────────   ──────────────────   ──────────────────
+ *   needs_analysis       Needs Analysis       Needs Analysis
+ *   NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
+ *   unitPrice            Unit Price           UnitPrice            <- differ
+ *   BestCase             Best Case            BestCase             <- differ
+ *   lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
+ *
+ * They are fed different inputs, which is why their outputs may differ. A field
+ * KEY is authored in the codebase and is expected to carry a machine spelling,
+ * so splitting camelCase recovers words its author meant. A stored VALUE is
+ * arbitrary tenant data — a picklist member, an object name, a code from
+ * another system — where a mid-token capital is not reliably a word boundary,
+ * and splitting it rewrites what the tenant wrote (`McDonald` -> `Mc Donald`).
+ * Note also that the two conventions do not nest: on the last row above each
+ * leaves alone the separator the other rewrites, so "converge" would have to
+ * pick a winner per input class rather than adopt one side wholesale.
+ *
+ * Kept distinct DELIBERATELY, and this paragraph is the write-down whose
+ * absence made the split read as drift. Converging them is a decision, not a
+ * refactor: this function is read by grid, gantt, detail and charts, so any
+ * change to what it RETURNS moves rendered output in four packages at once.
+ * That change is explicitly out of scope for the convergence that created this
+ * module; it needs its own card.
+ *
+ * Examples:
+ *   "in_progress"   -> "In Progress"
+ *   "high-priority" -> "High Priority"
+ *   "active"        -> "Active"
+ */
+export declare function humanizeLabel(value: string): string;

package/dist/utils/humanize-label.js

@@ -0,0 +1,62 @@
+/**
+ * ObjectUI — value-fallback label prettifier
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/**
+ * humanize-label — the ONE home for the VALUE fallback: a stored value becomes
+ * a display string when nothing else resolves it (objectui#5444).
+ *
+ * Two byte-identical copies preceded this module: `@object-ui/fields` (read by
+ * `plugin-grid`, `plugin-gantt`, `plugin-detail`, and by the field renderers in
+ * that package itself) and a deliberate local copy in `plugin-charts`'
+ * `ObjectChart.tsx`, whose comment said it existed "to avoid a dependency on
+ * `@object-ui/fields`". `@object-ui/core` is the shared ancestor both packages
+ * already depend on, so the convention gets a single home without a new
+ * dependency edge and without React reaching core — objectui#4389's ruling for
+ * this family: core-canonical logic, plugins consume; never core importing
+ * react. Both former sites now re-export THIS function, so there is one
+ * implementation and two doorways.
+ *
+ * ## Why this is NOT `humanizeFieldKey`, and why the two are kept apart
+ *
+ * The renderer carries a second prettifier — `humanizeFieldKey` in
+ * `@object-ui/plugin-dashboard`, the single home for the KEY fallback (a field
+ * key becomes a column header). It is a DIFFERENT convention, not a stale copy
+ * of this one: it additionally splits camelCase.
+ *
+ *   input                humanizeFieldKey     humanizeLabel (here)
+ *   ──────────────────   ──────────────────   ──────────────────
+ *   needs_analysis       Needs Analysis       Needs Analysis
+ *   NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
+ *   unitPrice            Unit Price           UnitPrice            <- differ
+ *   BestCase             Best Case            BestCase             <- differ
+ *   lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
+ *
+ * They are fed different inputs, which is why their outputs may differ. A field
+ * KEY is authored in the codebase and is expected to carry a machine spelling,
+ * so splitting camelCase recovers words its author meant. A stored VALUE is
+ * arbitrary tenant data — a picklist member, an object name, a code from
+ * another system — where a mid-token capital is not reliably a word boundary,
+ * and splitting it rewrites what the tenant wrote (`McDonald` -> `Mc Donald`).
+ * Note also that the two conventions do not nest: on the last row above each
+ * leaves alone the separator the other rewrites, so "converge" would have to
+ * pick a winner per input class rather than adopt one side wholesale.
+ *
+ * Kept distinct DELIBERATELY, and this paragraph is the write-down whose
+ * absence made the split read as drift. Converging them is a decision, not a
+ * refactor: this function is read by grid, gantt, detail and charts, so any
+ * change to what it RETURNS moves rendered output in four packages at once.
+ * That change is explicitly out of scope for the convergence that created this
+ * module; it needs its own card.
+ *
+ * Examples:
+ *   "in_progress"   -> "In Progress"
+ *   "high-priority" -> "High Priority"
+ *   "active"        -> "Active"
+ */
+export function humanizeLabel(value) {
+    return value.replace(/[_-]/g, ' ').replace(/\b\w/g, c => c.toUpperCase());
+}

package/dist/utils/managedBy.d.ts

@@ -51,8 +51,33 @@ export type UserActionOverride = boolean | {
     disabledWhen?: RowCrudPredicates['disabledWhen'];
 };
 export interface UserActionsOverride {
-    create?: boolean;
-    import?: boolean;
+    /**
+     * Bare boolean or the object form. Widened from `boolean` in objectui#4646:
+     * `@objectstack/spec@17.0.0` types this key
+     * `z.union([z.boolean(), RowCrudActionOverrideSchema])`, and the spec's
+     * resolver emits the parsed predicates as `CrudAffordances.createPredicates`.
+     * The local type said `boolean` — so an author writing the shape the spec
+     * accepts, and that the related-list toolbar now honours
+     * (`RelatedRecordActionsBridge`, objectui#4646), was rejected by objectui's
+     * own type while the runtime handled it.
+     */
+    create?: UserActionOverride;
+    /**
+     * Bare boolean or the object form — the SAME union as `create` above, which
+     * is how `@objectstack/spec@17.0.0` types the two toolbar keys
+     * (`z.union([z.boolean(), RowCrudActionOverrideSchema])` for each), and its
+     * resolver emits `CrudAffordances.importPredicates` beside
+     * `createPredicates`.
+     *
+     * Widened in objectui#5142, deliberately IN THE SAME change that gave the
+     * object-list toolbar's Import button a consumer for those predicates
+     * (`ObjectView`). objectui#4646 left this key narrow on purpose and said why:
+     * widening a type ahead of its consumer re-declares the inert-metadata defect
+     * — objectui would have *claimed* to accept the object form while still
+     * dropping the predicate. Type and consumer travel together, so the
+     * declaration stays an honest statement of what this renderer honours.
+     */
+    import?: UserActionOverride;
     edit?: UserActionOverride;
     delete?: UserActionOverride;
     exportCsv?: boolean;

package/dist/utils/normalize-list-view.d.ts

@@ -35,13 +35,33 @@ export declare const DENSITY_MODE_TO_ROW_HEIGHT: Record<DensityMode, RowHeight>;
  */
 export declare const ROW_HEIGHT_TO_DENSITY_MODE: Record<RowHeight, DensityMode>;
 /**
- * Tolerant reader for {@link ROW_HEIGHT_TO_DENSITY_MODE}. View metadata is
- * user-authored, so `rowHeight` is not guaranteed to be one of the five spec
- * values — an unknown one lands on `comfortable` rather than rendering an
- * undefined density. Keeping the fallback here means every surface collapses
- * the same way.
+ * Runtime reader for {@link ROW_HEIGHT_TO_DENSITY_MODE}: the spec's five row
+ * heights narrowed onto the renderer's three densities, and **nothing else**.
+ *
+ * The parameter stays `unknown` because this is the boundary user-authored view
+ * metadata actually crosses — `ListViewSchema.rowHeight` is statically a
+ * `RowHeight`, but the value arrives from stored view definitions TypeScript
+ * never saw (`ObjectView`: `viewDef.rowHeight ?? listSchema.rowHeight`). The
+ * type-level half of the guarantee is the `Record<RowHeight, …>` on the table
+ * above, which fails the build when the spec grows a row height.
+ *
+ * An off-spec value gets NO density (objectui#4440). It used to be coerced to
+ * `comfortable`, which is the opposite of what `@object-ui/react`'s spec bridge
+ * answers for the same string after objectui#4352 — one metadata-driven system
+ * holding two answers for one input. AGENTS.md #0.1 decides which one survives:
+ * a renderer-side rehabilitation of off-spec metadata is a second de-facto
+ * contract, and one strict contract beats N. The producer is where a bad
+ * `rowHeight` gets fixed.
+ *
+ * Callers apply their own "nothing was said" default to `undefined`, so an
+ * off-spec row height now renders exactly like an absent one — `'compact'` in
+ * both `ListView` and `ObjectGrid`.
+ *
+ * `hasOwnProperty`, not `in`: `in` walks the prototype chain, so `'toString'`
+ * used to come back as `Object.prototype.toString` — a FUNCTION returned from
+ * something typed `DensityMode`.
  */
-export declare function rowHeightToDensityMode(rowHeight: unknown): DensityMode;
+export declare function rowHeightToDensityMode(rowHeight: unknown): DensityMode | undefined;
 /**
  * ObjectUI's `list-view` node historically used a different vocabulary from
  * `@objectstack/spec` for the same concepts (`fields` where the spec says
@@ -105,5 +125,15 @@ export declare function rowHeightToDensityMode(rowHeight: unknown): DensityMode;
  *    breaking change with no inventory. Runs AFTER the `fields` → `columns` fold
  *    above, so a view that spells its column list the legacy way still gets its
  *    entries canonicalized.
+ *  - the four PER-VIEW-TYPE config aliases phase 3 carried over
+ *    ({@link PER_VIEW_CONFIG_ALIASES}): `kanban.groupField` → `groupByField`,
+ *    `kanban.cardFields` → `columns`, `gallery.imageField` → `coverField`,
+ *    `timeline.dateField` → `startDateField`. One read-site changes behaviour
+ *    as a result, and it is a CORRECTION of the same inverted precedence A2
+ *    fixed for `densityMode`: `ListView`'s kanban adapter resolves
+ *    `cardFields || columns`, i.e. legacy over canonical, so a config carrying
+ *    BOTH used to render the legacy value. After the fold the canonical
+ *    `columns` reaches it. Every other reader of these four was already
+ *    canonical-first and is unaffected.
  */
 export declare function normalizeListViewSchema<T>(schema: T): T;