@object-ui/core 17.3.0 → 17.6.0

package/dist/utils/normalize-list-view.js

@@ -32,17 +32,39 @@ export const ROW_HEIGHT_TO_DENSITY_MODE = {
     extra_tall: 'spacious',
 };
 /**
- * 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 function rowHeightToDensityMode(rowHeight) {
-    if (typeof rowHeight === 'string' && rowHeight in ROW_HEIGHT_TO_DENSITY_MODE) {
-        return ROW_HEIGHT_TO_DENSITY_MODE[rowHeight];
+    if (typeof rowHeight !== 'string')
+        return undefined;
+    if (!Object.prototype.hasOwnProperty.call(ROW_HEIGHT_TO_DENSITY_MODE, rowHeight)) {
+        return undefined;
     }
-    return 'comfortable';
+    return ROW_HEIGHT_TO_DENSITY_MODE[rowHeight];
 }
 const isRecord = (v) => !!v && typeof v === 'object' && !Array.isArray(v);
 /**
@@ -79,6 +101,32 @@ const ARIA_KEY_ALIASES = {
     label: 'ariaLabel',
     describedBy: 'ariaDescribedBy',
 };
+/**
+ * Per-view-type config aliases → the spec key each one aliases (#2890, the
+ * phase-3 carry-over).
+ *
+ * Phase 3 derived `kanban` / `gallery` / `timeline` from the spec configs but
+ * kept the pre-#2231 objectui spellings declared alongside the spec keys so
+ * stored view metadata would keep validating
+ * (`packages/types/src/zod/objectql.zod.ts`, each marked `@deprecated legacy
+ * alias for the spec's X`). Folding them here is what lets a read-site stop
+ * carrying its own `canonical || legacy` pair — the same move A1–A5 made for
+ * the top-level vocabulary.
+ *
+ * `calendar` is deliberately absent: its one local key, `defaultView`, is not
+ * an alias of anything. It has no spec counterpart at all, so it wants
+ * PROMOTION upstream, not a rename — folding it would delete an authored value
+ * with nowhere to put it.
+ *
+ * Note `kanban.columns` is the spec's "fields shown on each card", NOT the
+ * table columns that the same word names at the ListView top level. The fold
+ * is scoped to the nested config, so the two never meet.
+ */
+const PER_VIEW_CONFIG_ALIASES = {
+    kanban: { groupField: 'groupByField', cardFields: 'columns' },
+    gallery: { imageField: 'coverField' },
+    timeline: { dateField: 'startDateField' },
+};
 /**
  * ObjectUI's `list-view` node historically used a different vocabulary from
  * `@objectstack/spec` for the same concepts (`fields` where the spec says
@@ -142,6 +190,16 @@ const ARIA_KEY_ALIASES = {
  *    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 function normalizeListViewSchema(schema) {
     if (!schema || typeof schema !== 'object')
@@ -173,9 +231,22 @@ export function normalizeListViewSchema(schema) {
             : undefined;
     const foldedColumns = normalizeColumnIdentities(columnsSource);
     const foldColumnIdentity = foldedColumns !== columnsSource;
+    // Per-view-type config aliases (#2890 phase-3 carry-over). Collected before
+    // the early return so an otherwise-canonical view carrying only a nested
+    // legacy key still folds — and so a view carrying none still returns by
+    // reference.
+    const perViewFolds = Object.entries(PER_VIEW_CONFIG_ALIASES)
+        .map(([viewKey, aliases]) => {
+        const cfg = isRecord(s[viewKey]) ? s[viewKey] : undefined;
+        if (!cfg)
+            return undefined;
+        const legacyKeys = Object.keys(aliases).filter((legacy) => cfg[legacy] !== undefined);
+        return legacyKeys.length ? { viewKey, aliases, cfg, legacyKeys } : undefined;
+    })
+        .filter((entry) => entry !== undefined);
     if (!foldColumns && !foldRowHeight && !foldFilter && !legacyFlags.length &&
         !foldDescription && !foldAria && !foldSharing && !defaultViewKind &&
-        !foldColumnIdentity) {
+        !foldColumnIdentity && !perViewFolds.length) {
         return schema;
     }
     const next = { ...s };
@@ -249,6 +320,19 @@ export function normalizeListViewSchema(schema) {
         delete nextSharing.enabled;
         next.sharing = nextSharing;
     }
+    for (const { viewKey, aliases, cfg, legacyKeys } of perViewFolds) {
+        const nextCfg = { ...cfg };
+        for (const legacy of legacyKeys) {
+            const canonical = aliases[legacy];
+            // Same one-directional shape as every fold above: the canonical key wins
+            // when both are present, and the legacy key is REMOVED so a missed
+            // read-site fails loudly instead of quietly taking the legacy path.
+            if (nextCfg[canonical] === undefined)
+                nextCfg[canonical] = cfg[legacy];
+            delete nextCfg[legacy];
+        }
+        next[viewKey] = nextCfg;
+    }
     if (defaultViewKind)
         next.viewType = 'grid';
     return next;

package/dist/utils/number-display.d.ts

@@ -0,0 +1,155 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * `formatDisplayNumber` — the ONE number-display formatter behind every field
+ * cell, field widget, metric renderer and dataset measure in the console.
+ *
+ * It exists because the same `new Intl.NumberFormat('en-US', …)` construction
+ * had been copied into the number cell renderer, the currency cell renderer,
+ * the currency widget, the compact `formatNumber` helper and the dashboard
+ * metric widget. Two defects therefore had five homes each, and fixing "the"
+ * renderer never changed the answer (objectui#4033, source thread
+ * objectstack#5067):
+ *
+ *  1. the locale was hardcoded to `en-US`, so a `zh-CN` / `de-DE` console still
+ *     grouped and pointed decimals the US way; and
+ *  2. `useGrouping` was never set, so a four-digit YEAR stored as
+ *     `Field.number({ scale: 0 })` rendered as `2,026` — in every locale, with
+ *     no field property able to turn it off.
+ *
+ * Both policies now live here and nowhere else. Call sites bring the value and
+ * the display width; they do not bring a locale default and they do not decide
+ * grouping.
+ *
+ * ── Why this module lives in `@object-ui/core` (objectui#4576) ──
+ * It used to live in `@object-ui/i18n`, and that home cost the repo a real
+ * defect. `@object-ui/core`'s `utils/dataset-format.ts` could not import it —
+ * `core` is the React-free engine (AGENTS.md §3: "No UI-lib deps. Logic only.")
+ * and is a runtime dependency of React-FREE consumers (the `object-ui` VS Code
+ * extension, `@object-ui/data-objectstack`), while `i18n` depends on
+ * `i18next`/`react-i18next` and peer-depends on React. So `formatMeasure` kept
+ * a parallel `Intl` implementation, the two drifted, and a German session read
+ * `1.234,5 %` from a list cell beside `1.234,5%` from a dashboard measure
+ * (objectui#4576). #4577 measured the option mapping LOSSLESS across 32,760
+ * combinations and recorded the duplication at both ends rather than routing
+ * through a boundary it could not cross.
+ *
+ * The function is pure — no React, no i18next, no DOM — so the boundary was
+ * never a property of the CODE, only of where the code sat. Moving it DOWN to
+ * the lower layer removes the obstacle instead of working around it:
+ * `@object-ui/i18n` now RE-EXPORTS these three names, so every existing import
+ * path keeps compiling and `import { formatDisplayNumber } from '@object-ui/i18n'`
+ * and `from '@object-ui/core'` are the SAME symbol (pinned in
+ * `packages/i18n/src/__tests__/number-display.reexport-identity.test.ts`).
+ * `core` imports `i18n` nowhere, so the new edge introduces no cycle.
+ */
+export interface DisplayNumberFormatOptions {
+    /**
+     * BCP-47 tag for the ACTIVE display locale — in React, whatever
+     * `useDisplayLocale()` returns.
+     *
+     * `undefined` means "follow the runtime default", which is the honest answer
+     * for a non-React caller that has no locale in hand. It never means `en-US`:
+     * assuming US conventions for the whole world is the defect this module was
+     * created to remove.
+     */
+    locale?: string;
+    /**
+     * ISO 4217 code. When present the value is formatted as money — which also
+     * means grouping is kept, because a grouped amount is what every currency
+     * convention expects and an ordinal amount of money is not a thing.
+     *
+     * Money wins over {@link DisplayNumberFormatOptions.style}: a call that sets
+     * both gets a currency rendering. Nothing in the repo does that, and the
+     * combination has no meaning to express.
+     */
+    currency?: string;
+    /**
+     * The FIELD's declared `scale` — the `s` of a `decimal(p, s)` column — and
+     * nothing else. This is a POLICY input, not a display width: pass it only
+     * when a field declaration actually said so.
+     *
+     * `scale: 0` with no currency declares a discrete integer (a year, a fiscal
+     * period, an ordinal), and those are not grouped. Leave `scale` undefined and
+     * grouping is kept — which is correct for the two cases that look similar but
+     * are not:
+     *
+     *   - an UNDECLARED scale (`scale` is optional in the spec, so absent means
+     *     "decimals unknown", not "integer"); and
+     *   - a caller whose zero-decimal display comes from something other than a
+     *     field declaration — e.g. the dashboard `MetricWidget`, whose decimals
+     *     come from a numeral.js format pattern and whose large KPI aggregates
+     *     are *documented* to want separators ("`1,930,000` not `1930000`").
+     *
+     * ⚠️ INTERIM DEFAULT (objectui#4033, PM ruling 2026-08-11). Suppressing
+     * grouping for every scale-0 number is a transitional policy with a known,
+     * accepted cost: a large scale-0 COUNT loses its separators too. It is the
+     * better trade only until the spec gains an authorable presentation hint
+     * (`useGrouping` / `displayFormat` — being specified separately, contract-first,
+     * in the objectstack repo). When that hint lands it OVERRIDES this default,
+     * and this heuristic should be reduced to the fallback for fields that
+     * declare nothing.
+     */
+    scale?: number;
+    /**
+     * How the number relates to a percentage — the ONE place that distinction is
+     * expressed, because getting it wrong is the whole of objectui#4576.
+     *
+     *  - `'decimal'` (default) — a plain number, no percent sign.
+     *  - `'percent'` — the value is a FRACTION. `Intl` multiplies it by 100 and
+     *    appends the locale's percent convention, so `0.8` renders as `80%`.
+     *  - `'percentPoints'` — the value is ALREADY in percentage points, so `80`
+     *    renders as `80%`. Same locale convention, NO re-scaling.
+     *
+     * The third one exists because "divide by 100 so `Intl` can multiply it back"
+     * is not free, and the round trip is lossy at rounding TIES: measured on this
+     * repo's runner, `80.175` percentage points formatted to 2 decimals renders
+     * `80.18%` when formatted directly and `80.17%` after the divide-and-remultiply
+     * — 27,581 of 1,200,013 ordinary-magnitude en-US forms move, plus every
+     * value at the top of the double range (`MAX_SAFE_INTEGER`, `1e23`). That
+     * count is objectui#4576's tie-dense grid — 0.005 steps to 2,000, precisions
+     * 0/1/2 — measured on `formatDisplayNumber` / `formatMeasure`'s call shape.
+     * objectui#4590 re-measured the same route through `formatPercent` and
+     * reports 27,577 of 1,200,003: a different form set, not a correction of this
+     * one. A caller holding percentage points must therefore NOT reach for
+     * `'percent'`; that is exactly the trap this option removes.
+     *
+     * `'percentPoints'` is implemented with `Intl`'s `style: 'unit'` /
+     * `unit: 'percent'`, which was measured to produce a BYTE-IDENTICAL percent
+     * affix to `style: 'percent'` across all 171 locale tags tested — including
+     * the German/French/Russian no-break space before the sign, Turkish's PREFIX
+     * position (`%1.234,5`), Arabic's own percent sign plus U+061C, and the
+     * Bengali/Marathi percent patterns that group Western-style where their
+     * decimal patterns group by lakh. It is the same CONVENTION by a route that
+     * does not touch the value.
+     */
+    style?: 'decimal' | 'percent' | 'percentPoints';
+    minimumFractionDigits?: number;
+    maximumFractionDigits?: number;
+    notation?: 'standard' | 'compact';
+}
+/**
+ * The grouping policy, alone and testable: does this number get thousands
+ * separators?
+ *
+ * @param scale    the field's declared `scale`, or `undefined` when the caller
+ *                 has no field declaration behind it
+ * @param currency ISO 4217 code when the number is money
+ */
+export declare function shouldGroupDisplayNumber(scale?: number, currency?: string): boolean;
+/**
+ * Format a number for DISPLAY, in the active locale, under the grouping policy
+ * above.
+ *
+ * Throws for a bad `currency` code exactly as `Intl.NumberFormat` does, so the
+ * fallbacks call sites already had (`${currency} ${value.toFixed(n)}`) keep
+ * working unchanged. A bad LOCALE is handled here instead of throwing: `locale`
+ * arrives from a server response (ADR-0053 `localization.locale`), and a
+ * malformed tag from a tenant config must never take a grid cell down.
+ */
+export declare function formatDisplayNumber(value: number, options?: DisplayNumberFormatOptions): string;

package/dist/utils/number-display.js

@@ -0,0 +1,71 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * The grouping policy, alone and testable: does this number get thousands
+ * separators?
+ *
+ * @param scale    the field's declared `scale`, or `undefined` when the caller
+ *                 has no field declaration behind it
+ * @param currency ISO 4217 code when the number is money
+ */
+export function shouldGroupDisplayNumber(scale, currency) {
+    // Money always groups — including money whose currency code could not be
+    // resolved, which still renders as an amount (just without a symbol).
+    if (currency)
+        return true;
+    // Only an explicitly declared scale of 0 is an ordinal. `undefined !== 0`.
+    return scale !== 0;
+}
+/**
+ * Format a number for DISPLAY, in the active locale, under the grouping policy
+ * above.
+ *
+ * Throws for a bad `currency` code exactly as `Intl.NumberFormat` does, so the
+ * fallbacks call sites already had (`${currency} ${value.toFixed(n)}`) keep
+ * working unchanged. A bad LOCALE is handled here instead of throwing: `locale`
+ * arrives from a server response (ADR-0053 `localization.locale`), and a
+ * malformed tag from a tenant config must never take a grid cell down.
+ */
+export function formatDisplayNumber(value, options = {}) {
+    const { locale, currency, scale, style, ...passthrough } = options;
+    const intlOptions = { ...passthrough };
+    if (style === 'percentPoints') {
+        // The locale's percent convention WITHOUT `style: 'percent'`'s ×100 — see
+        // the option's doc above for the measurement that separates the two.
+        intlOptions.style = 'unit';
+        intlOptions.unit = 'percent';
+        intlOptions.unitDisplay = 'narrow';
+    }
+    else if (style) {
+        intlOptions.style = style;
+    }
+    if (currency) {
+        intlOptions.style = 'currency';
+        intlOptions.currency = currency;
+        delete intlOptions.unit;
+        delete intlOptions.unitDisplay;
+    }
+    // ⚠️ Set `useGrouping` ONLY to suppress. `useGrouping: true` is NOT the same
+    // as omitting the key: `true` means "always", while omitting it means "auto"
+    // (and "min2" under compact notation), which is the locale's own preference.
+    // Measured — for 1234: es-ES "auto" → `1234` but "always" → `1.234`; pl-PL
+    // "auto" → `1234` but "always" → `1 234`. Writing `true` here would silently
+    // override those locales' conventions in the name of preserving en-US output.
+    if (!shouldGroupDisplayNumber(scale, currency)) {
+        intlOptions.useGrouping = false;
+    }
+    try {
+        return new Intl.NumberFormat(locale, intlOptions).format(value);
+    }
+    catch {
+        // Retry WITHOUT the locale, keeping every other option: this rescues a
+        // malformed tag while still surfacing a genuinely bad `currency` to the
+        // caller's own catch.
+        return new Intl.NumberFormat(undefined, intlOptions).format(value);
+    }
+}

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

@@ -30,6 +30,12 @@
  * more column and no extra round trip. (A relation that IS displayed still gets
  * expanded for its label, and `toPredicateRecord` collapses it back for the
  * predicate.)
+ *
+ * Since objectstack#8018 the same reader also carries the non-predicate row keys
+ * a view's actions read — today just `recordIdField`. The name kept the
+ * "predicate" spelling because the mechanism is identical (harvest a name, gate
+ * it against the declared fields, add it to `$select`); see
+ * {@link listViewPredicates} for what is in the set and why.
  */
 /**
  * The columns the framework provisions on EVERY business object
@@ -71,13 +77,32 @@ export declare function isProjectableField(name: string, declaredFields: Record<
  */
 export declare function collectPredicateFieldRefs(predicates: readonly unknown[]): string[];
 /**
- * Every predicate a list-ish view carries, flattened for
+ * Every record-field reference a list-ish view carries, flattened for
  * {@link collectPredicateFieldRefs}.
  *
  * One reader so the projection cannot fall behind the surfaces: each entry here
- * is a place a predicate is actually evaluated against a row — conditional
- * formatting, the row kebab (custom defs AND the built-in Edit/Delete
- * overrides), the selection bar, and the object's declared actions.
+ * is a place a row field is actually READ — conditional formatting, the row
+ * kebab (custom defs AND the built-in Edit/Delete overrides), the selection bar,
+ * and the object's declared actions.
+ *
+ * Most entries are predicates. Two are not, and both are spelled as a synthetic
+ * `record.<name>` so the one harvester handles them: conditional formatting's
+ * native `{ field, operator, value }` shape, and an action's `recordIdField`
+ * (objectstack#8018). The `recordIdField` case is the same *class* of bug the
+ * predicate harvest exists to close, one surface over — the action runtime reads
+ * `rowRecord[action.recordIdField]` to seed `recordIdParam`, so a key outside the
+ * listView columns arrived absent and the injection was silently skipped, which
+ * turns a record-scoped mutation into one that names no record while still
+ * reporting success. The default (`id`) is already projected unconditionally, so
+ * only an explicit declaration adds anything here.
+ *
+ * A `recordIdField` that is not a bare identifier is dropped here, and one naming
+ * a field the object does not declare is dropped by the caller's
+ * `isProjectableField` guard. Both drops are the safe direction: such a name is
+ * not a column anywhere, and an unknown key in `$select` is not ignored by every
+ * backend. The identifier gate is not decoration — without it the harvester's
+ * regex would read a PREFIX of a malformed name (`record.not a field` → `not`)
+ * and contribute a plausible wrong field instead of nothing.
  *
  * `objectActions` is deliberately the object's WHOLE action set rather than
  * only the ones this view promotes. Narrowing it would mean re-running the

package/dist/utils/predicate-fields.js

@@ -30,6 +30,12 @@
  * more column and no extra round trip. (A relation that IS displayed still gets
  * expanded for its label, and `toPredicateRecord` collapses it back for the
  * predicate.)
+ *
+ * Since objectstack#8018 the same reader also carries the non-predicate row keys
+ * a view's actions read — today just `recordIdField`. The name kept the
+ * "predicate" spelling because the mechanism is identical (harvest a name, gate
+ * it against the declared fields, add it to `$select`); see
+ * {@link listViewPredicates} for what is in the set and why.
  */
 /**
  * The columns the framework provisions on EVERY business object
@@ -74,6 +80,14 @@ export function isProjectableField(name, declaredFields) {
  * record-header path), so this covers the documented spelling.
  */
 const RECORD_REF = /\b(?:record|data)\.([A-Za-z_][A-Za-z0-9_]*)/g;
+/**
+ * A whole bare identifier — what a field name is, and the only shape that can be
+ * spelled as `record.<name>` without the harvester's regex reading a PREFIX of it
+ * as the name (`record.not a field` would otherwise yield `not`). Used to gate
+ * the non-predicate names folded into {@link listViewPredicates}, so a malformed
+ * declaration contributes nothing instead of contributing a plausible wrong name.
+ */
+const BARE_IDENTIFIER = /^[A-Za-z_][A-Za-z0-9_]*$/;
 /** Pull the CEL source out of any of the shapes a predicate is authored in. */
 function predicateSource(pred) {
     if (typeof pred === 'string')
@@ -117,13 +131,32 @@ export function collectPredicateFieldRefs(predicates) {
     return out;
 }
 /**
- * Every predicate a list-ish view carries, flattened for
+ * Every record-field reference a list-ish view carries, flattened for
  * {@link collectPredicateFieldRefs}.
  *
  * One reader so the projection cannot fall behind the surfaces: each entry here
- * is a place a predicate is actually evaluated against a row — conditional
- * formatting, the row kebab (custom defs AND the built-in Edit/Delete
- * overrides), the selection bar, and the object's declared actions.
+ * is a place a row field is actually READ — conditional formatting, the row
+ * kebab (custom defs AND the built-in Edit/Delete overrides), the selection bar,
+ * and the object's declared actions.
+ *
+ * Most entries are predicates. Two are not, and both are spelled as a synthetic
+ * `record.<name>` so the one harvester handles them: conditional formatting's
+ * native `{ field, operator, value }` shape, and an action's `recordIdField`
+ * (objectstack#8018). The `recordIdField` case is the same *class* of bug the
+ * predicate harvest exists to close, one surface over — the action runtime reads
+ * `rowRecord[action.recordIdField]` to seed `recordIdParam`, so a key outside the
+ * listView columns arrived absent and the injection was silently skipped, which
+ * turns a record-scoped mutation into one that names no record while still
+ * reporting success. The default (`id`) is already projected unconditionally, so
+ * only an explicit declaration adds anything here.
+ *
+ * A `recordIdField` that is not a bare identifier is dropped here, and one naming
+ * a field the object does not declare is dropped by the caller's
+ * `isProjectableField` guard. Both drops are the safe direction: such a name is
+ * not a column anywhere, and an unknown key in `$select` is not ignored by every
+ * backend. The identifier gate is not decoration — without it the harvester's
+ * regex would read a PREFIX of a malformed name (`record.not a field` → `not`)
+ * and contribute a plausible wrong field instead of nothing.
  *
  * `objectActions` is deliberately the object's WHOLE action set rather than
  * only the ones this view promotes. Narrowing it would mean re-running the
@@ -151,6 +184,13 @@ export function listViewPredicates(view) {
                 continue;
             const d = def;
             preds.push(d.visible, d.disabled);
+            // The row key this action identifies its record by — a field the runtime
+            // READS off the row, so the projection owes it exactly as it owes a
+            // predicate's operands. Spelled as a `record.` reference so the one
+            // harvester handles it (see the doc above).
+            if (typeof d.recordIdField === 'string' && BARE_IDENTIFIER.test(d.recordIdField)) {
+                preds.push(`record.${d.recordIdField}`);
+            }
         }
     }
     for (const override of Object.values(view.userActions ?? {})) {

package/dist/utils/resolve-view-id.d.ts

@@ -0,0 +1,31 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * Resolve a REQUESTED view name against an object's actual view ids.
+ *
+ * Canonical view ids are fully qualified (`<object>.<viewKind>`, see app-shell's
+ * MetadataProvider), but the surfaces that NAME a view emit the short form —
+ * nav items write their `viewName` verbatim, `ElementDataSource.view` on a page
+ * component is authored by hand, and legacy embedded `listViews` carry bare keys
+ * (including the `'all'` fallback view). Accept both directions (#2217):
+ *
+ * 1. exact id match;
+ * 2. short name (no `.`) → retry as `<objectName>.<name>`;
+ * 3. qualified name → retry with the `<objectName>.` prefix stripped.
+ *
+ * Returns the matching view id, or `undefined` when nothing matches — the
+ * caller decides how to fall back (and should report it rather than swallow it).
+ *
+ * Lives in `@object-ui/core` because it has two consumers in different layers:
+ * app-shell's `ObjectView` (URL-requested view) and the page-component data
+ * binding that resolves `dataSource.view` (objectstack#5576). A second copy at
+ * the second call site is the drift AGENTS.md #0.1 forbids — one matcher, one
+ * place, so a view name that resolves in the object page resolves identically
+ * when a page component names it.
+ */
+export declare function resolveViewId(requested: string | undefined | null, viewIds: readonly string[], objectName: string): string | undefined;

package/dist/utils/resolve-view-id.js

@@ -0,0 +1,45 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * Resolve a REQUESTED view name against an object's actual view ids.
+ *
+ * Canonical view ids are fully qualified (`<object>.<viewKind>`, see app-shell's
+ * MetadataProvider), but the surfaces that NAME a view emit the short form —
+ * nav items write their `viewName` verbatim, `ElementDataSource.view` on a page
+ * component is authored by hand, and legacy embedded `listViews` carry bare keys
+ * (including the `'all'` fallback view). Accept both directions (#2217):
+ *
+ * 1. exact id match;
+ * 2. short name (no `.`) → retry as `<objectName>.<name>`;
+ * 3. qualified name → retry with the `<objectName>.` prefix stripped.
+ *
+ * Returns the matching view id, or `undefined` when nothing matches — the
+ * caller decides how to fall back (and should report it rather than swallow it).
+ *
+ * Lives in `@object-ui/core` because it has two consumers in different layers:
+ * app-shell's `ObjectView` (URL-requested view) and the page-component data
+ * binding that resolves `dataSource.view` (objectstack#5576). A second copy at
+ * the second call site is the drift AGENTS.md #0.1 forbids — one matcher, one
+ * place, so a view name that resolves in the object page resolves identically
+ * when a page component names it.
+ */
+export function resolveViewId(requested, viewIds, objectName) {
+    if (!requested)
+        return undefined;
+    const has = (id) => viewIds.includes(id);
+    if (has(requested))
+        return requested;
+    const prefix = `${objectName}.`;
+    if (!requested.includes('.') && has(prefix + requested)) {
+        return prefix + requested;
+    }
+    if (requested.startsWith(prefix) && has(requested.slice(prefix.length))) {
+        return requested.slice(prefix.length);
+    }
+    return undefined;
+}