@object-ui/core 17.6.0 → 18.0.0

package/dist/utils/filter-tokens.d.ts

@@ -16,7 +16,7 @@ import { CONTEXT_TOKENS } from '@objectstack/spec/data';
  *
  *     { owner_id: '{current_user_id}' }
  *
- * ## Why this module exists (framework #3574)
+ * ## Why this module exists (objectstack-ai/objectstack#3574)
  *
  * There used to be no shared resolver. Three ad-hoc implementations had grown
  * up independently — one in `ObjectView` for list views, one in
@@ -40,6 +40,25 @@ import { CONTEXT_TOKENS } from '@objectstack/spec/data';
  * Dropping a `{current_user_id}` filter widens a view; it must never widen
  * access. Never use a context token as an access control.
  *
+ * ## `{record_id}` — the record in view, not the session (objectui#7297)
+ *
+ * `@objectstack/spec` declares one sibling of the two session tokens:
+ * `RECORD_CONTEXT_TOKENS` = `{record_id}`, the id of the record a
+ * `type: 'record'` page is showing (objectstack-ai/objectstack#20003). It is a
+ * separate list, not a member of `CONTEXT_TOKENS`, because it resolves against
+ * the SURFACE rather than the session, and only here: the server never knows
+ * which record a page shows, so it refuses a filter still carrying the token
+ * by name (`FILTER_TOKEN_UNRESOLVED`).
+ *
+ * Its value is `FilterTokenScope.recordId`, which `useFilterScope()` in
+ * `@object-ui/react` fills from the mounted `RecordContextProvider` and from
+ * nothing else — never a URL parameter, never a page variable. With no record
+ * in scope the token is refused by name through `onUnresolved`, in the voice
+ * an unresolved session token gets, and left as written: it never becomes
+ * `null` (a count about nobody) and its condition is never dropped (a count
+ * about everybody). Like the session tokens it scopes what a record page
+ * SHOWS; which of those rows the caller may read is still RLS's decision.
+ *
  * ## Contract source
  *
  * The canonical vocabulary is published as part of the platform contract at
@@ -53,6 +72,20 @@ import { CONTEXT_TOKENS } from '@objectstack/spec/data';
  * copy was byte-identical, so every value comparison and every behavioural
  * test passed while it sat here. Reference identity is the one check that
  * distinguishes a re-export from a fork (objectui#3003).
+ *
+ * The same argument retired the two module-local copies that sat beside it
+ * until objectui#7265 — the near-miss suggestion map and the membership
+ * predicate are imported from `@objectstack/spec/data` now, so neither can
+ * drift either. Both were re-measured against the RESOLVED pin (17.4.0; the
+ * card had measured 17.2.0) before the swap, because "byte-identical" is a
+ * statement about a version, not a property: the map matched on nine keys, in
+ * the same order, with the same values, and the two predicates agreed on every
+ * one of 61 real vocabulary members — the token tuple, both suggestion key
+ * sets, the date-macro tokens and their aliases, plus casing, whitespace and
+ * prototype-key spellings. Each comparison ran a lit control of the same kind
+ * through the same comparator (the spec's own token-description map, and its
+ * date-macro predicate), so "no difference" came from an instrument shown able
+ * to report one.
  */
 /** The complete set of session-scoped filter tokens (spec-owned, re-exported). */
 export { CONTEXT_TOKENS };
@@ -63,15 +96,26 @@ export interface FilterTokenScope {
     currentUserId?: string | null;
     /** The active organization id. */
     currentOrgId?: string | null;
+    /**
+     * The id of the record the surface is bound to, which resolves
+     * `{record_id}` (objectui#7297): the mounted record context of a
+     * `type: 'record'` page. `useFilterScope()` in `@object-ui/react` fills it
+     * from the nearest `RecordContextProvider`, and a host that renders no
+     * record leaves it unset, so the token is refused there. ⛔ Never fill it
+     * from a URL parameter or a page variable.
+     */
+    recordId?: string | null;
     /**
      * Called when a placeholder cannot be resolved — either a recognised token
-     * with no value in scope (signed out), or a near-miss spelling that resolves
-     * in no vocabulary. Defaults to a `console.warn`; pass `null` to silence.
+     * with no value in scope (signed out, or no record in context), or a
+     * near-miss spelling that resolves in no vocabulary. Defaults to a
+     * `console.warn`; pass `null` to silence.
      */
     onUnresolved?: ((message: string) => void) | null;
 }
 /**
- * Expand `{current_user_id}` / `{current_org_id}` inside a filter.
+ * Expand `{current_user_id}` / `{current_org_id}`, and `{record_id}` where a
+ * record is in scope, inside a filter.
  *
  * Walks arrays and plain objects recursively, which is what makes one
  * resolver cover both platform filter shapes: the MongoDB-style object a
@@ -98,7 +142,7 @@ export declare function resolveContextTokens<T = any>(filter: T, scope?: FilterT
  * macros and context tokens — in one call.
  *
  * This is the function surfaces should call. Calling only one of the two
- * resolvers is the defect behind framework #3574: dashboard widgets called
+ * resolvers is the defect behind objectstack-ai/objectstack#3574: dashboard widgets called
  * `resolveDateMacros` alone, so `{today}` worked and `{current_user_id}`
  * silently did not.
  *

package/dist/utils/filter-tokens.js

@@ -5,7 +5,7 @@
  * This source code is licensed under the MIT license found in the
  * LICENSE file in the root directory of this source tree.
  */
-import { CONTEXT_TOKENS } from '@objectstack/spec/data';
+import { CONTEXT_TOKENS, CONTEXT_TOKEN_SUGGESTIONS, isContextToken, isRecordContextToken, } from '@objectstack/spec/data';
 import { resolveDateMacros } from './date-macros.js';
 /**
  * Session-scoped filter placeholders — the sibling vocabulary to
@@ -17,7 +17,7 @@ import { resolveDateMacros } from './date-macros.js';
  *
  *     { owner_id: '{current_user_id}' }
  *
- * ## Why this module exists (framework #3574)
+ * ## Why this module exists (objectstack-ai/objectstack#3574)
  *
  * There used to be no shared resolver. Three ad-hoc implementations had grown
  * up independently — one in `ObjectView` for list views, one in
@@ -41,6 +41,25 @@ import { resolveDateMacros } from './date-macros.js';
  * Dropping a `{current_user_id}` filter widens a view; it must never widen
  * access. Never use a context token as an access control.
  *
+ * ## `{record_id}` — the record in view, not the session (objectui#7297)
+ *
+ * `@objectstack/spec` declares one sibling of the two session tokens:
+ * `RECORD_CONTEXT_TOKENS` = `{record_id}`, the id of the record a
+ * `type: 'record'` page is showing (objectstack-ai/objectstack#20003). It is a
+ * separate list, not a member of `CONTEXT_TOKENS`, because it resolves against
+ * the SURFACE rather than the session, and only here: the server never knows
+ * which record a page shows, so it refuses a filter still carrying the token
+ * by name (`FILTER_TOKEN_UNRESOLVED`).
+ *
+ * Its value is `FilterTokenScope.recordId`, which `useFilterScope()` in
+ * `@object-ui/react` fills from the mounted `RecordContextProvider` and from
+ * nothing else — never a URL parameter, never a page variable. With no record
+ * in scope the token is refused by name through `onUnresolved`, in the voice
+ * an unresolved session token gets, and left as written: it never becomes
+ * `null` (a count about nobody) and its condition is never dropped (a count
+ * about everybody). Like the session tokens it scopes what a record page
+ * SHOWS; which of those rows the caller may read is still RLS's decision.
+ *
  * ## Contract source
  *
  * The canonical vocabulary is published as part of the platform contract at
@@ -54,40 +73,47 @@ import { resolveDateMacros } from './date-macros.js';
  * copy was byte-identical, so every value comparison and every behavioural
  * test passed while it sat here. Reference identity is the one check that
  * distinguishes a re-export from a fork (objectui#3003).
+ *
+ * The same argument retired the two module-local copies that sat beside it
+ * until objectui#7265 — the near-miss suggestion map and the membership
+ * predicate are imported from `@objectstack/spec/data` now, so neither can
+ * drift either. Both were re-measured against the RESOLVED pin (17.4.0; the
+ * card had measured 17.2.0) before the swap, because "byte-identical" is a
+ * statement about a version, not a property: the map matched on nine keys, in
+ * the same order, with the same values, and the two predicates agreed on every
+ * one of 61 real vocabulary members — the token tuple, both suggestion key
+ * sets, the date-macro tokens and their aliases, plus casing, whitespace and
+ * prototype-key spellings. Each comparison ran a lit control of the same kind
+ * through the same comparator (the spec's own token-description map, and its
+ * date-macro predicate), so "no difference" came from an instrument shown able
+ * to report one.
  */
 /** The complete set of session-scoped filter tokens (spec-owned, re-exported). */
 export { CONTEXT_TOKENS };
-/**
- * Near-miss spellings → the token the author meant.
- *
- * Every entry is a real authoring mistake, and each is a correct spelling
- * *somewhere else* in the platform, which is exactly why authors reach for it:
- * `current_user` is the RLS expression root, `{user_id}` is valid
- * `titleFormat` field interpolation, `organization_id` is a real column name.
- *
- * Mirrors `CONTEXT_TOKEN_SUGGESTIONS` in `@objectstack/spec`. Used only to
- * make the runtime warning actionable; the authoring-time gate
- * (`validateFilterTokens` in `@objectstack/lint`) is what actually prevents
- * these from shipping.
- */
-const CONTEXT_TOKEN_SUGGESTIONS = {
-    current_user: 'current_user_id',
-    current_user_email: 'current_user_id',
-    user_id: 'current_user_id',
-    userid: 'current_user_id',
-    me: 'current_user_id',
-    current_organization_id: 'current_org_id',
-    org_id: 'current_org_id',
-    organization_id: 'current_org_id',
-    current_tenant_id: 'current_org_id',
-};
 /** Whole-string placeholder: `{token}` or `${token}`, anchored. */
 const WHOLE_TOKEN_RE = /^\$?\{([a-zA-Z0-9_]+)\}$/;
-function isContextToken(token) {
-    return CONTEXT_TOKENS.includes(token);
-}
 /**
- * Expand `{current_user_id}` / `{current_org_id}` inside a filter.
+ * A null-prototype copy of the spec's near-miss suggestion map (objectui#9129).
+ *
+ * `CONTEXT_TOKEN_SUGGESTIONS` is a plain object, so indexing it with an
+ * author-controlled, lower-cased string reaches `Object.prototype` for any
+ * spelling that happens to be an inherited member name — `constructor` and
+ * `__proto__` today, and, silently, whichever future member is added in
+ * lower case (see the lookup below). This is a read-only console hint, never
+ * an assignment, so no filter value is ever widened, narrowed or mismatched
+ * by it; the only externally visible effect of the underlying bug is a
+ * confusing suggestion string in a `warn()` call.
+ *
+ * Copying into an `Object.create(null)` base closes the whole class rather
+ * than special-casing the two spellings measured today: this object has no
+ * prototype at all, so *no* key — known or future — can resolve through it.
+ * `@objectstack/spec`'s own map is left untouched (out of scope here; the
+ * identical shape in its `classifyFilterToken` is the one objectstack `4342c9923` closed).
+ */
+const NEAR_MISS_SUGGESTIONS = Object.assign(Object.create(null), CONTEXT_TOKEN_SUGGESTIONS);
+/**
+ * Expand `{current_user_id}` / `{current_org_id}`, and `{record_id}` where a
+ * record is in scope, inside a filter.
  *
  * Walks arrays and plain objects recursively, which is what makes one
  * resolver cover both platform filter shapes: the MongoDB-style object a
@@ -111,17 +137,30 @@ function isContextToken(token) {
 export function resolveContextTokens(filter, scope = {}) {
     if (filter == null)
         return filter;
-    const { currentUserId, currentOrgId } = scope;
+    const { currentUserId, currentOrgId, recordId } = scope;
     const warn = scope.onUnresolved === null
         ? () => { }
         : scope.onUnresolved ??
             ((message) => {
                 console.warn(`[object-ui] ${message}`);
             });
+    // Annotated `Record<string, …>` because the spec's predicate returns a plain
+    // `boolean`, not the narrowing `token is ContextTokenName` the deleted local
+    // copy declared, so the narrowed branch below hands this lookup a `string`.
+    // The `satisfies` clause keeps the one thing that narrowing bought: a third
+    // context token in the spec reds this literal at compile time instead of
+    // resolving to `undefined` at runtime.
     const values = {
         current_user_id: currentUserId,
         current_org_id: currentOrgId,
     };
+    // The record-context sibling, kept apart for the reason the spec keeps the
+    // two lists apart: it is filled from the record in view, never from the
+    // session. The same `satisfies` ratchet: a second record-context token in
+    // the spec reds this literal at compile time.
+    const recordValues = {
+        record_id: recordId,
+    };
     const walk = (value) => {
         if (value == null)
             return value;
@@ -137,10 +176,36 @@ export function resolveContextTokens(filter, scope = {}) {
                 warn(`Filter placeholder "{${token}}" could not be resolved — no ${token === 'current_user_id' ? 'signed-in user' : 'active organization'} in scope. The filter will match no records.`);
                 return value;
             }
+            // `{record_id}` (objectui#7297). Resolved only from the record in scope.
+            // With none, it is refused BY NAME, in the voice of the unresolved
+            // session token above, and left as written: never `null` (a count about
+            // nobody), never dropped (a count about everybody), and never reported as
+            // an unknown spelling, because the spelling is right and the surface is
+            // not. The ObjectStack server then refuses the same filter by name
+            // (`FILTER_TOKEN_UNRESOLVED`), since no server path has a record in view.
+            if (isRecordContextToken(token)) {
+                const resolved = recordValues[token];
+                if (resolved != null && resolved !== '')
+                    return resolved;
+                warn(`Filter placeholder "{${token}}" could not be resolved — no record in context ` +
+                    `on this surface. It resolves only on a component of a \`type: 'record'\` page, ` +
+                    `to the id of the record that page shows. It is left as written, so the filter ` +
+                    `never widens: the server refuses it by name, and a backend with no resolver ` +
+                    `matches no records.`);
+                return value;
+            }
             // Not ours. Warn only for near-misses, which resolve in no vocabulary
             // at all and would otherwise fail silently; genuine date macros and
             // nav context-selector ids must pass through quietly.
-            const suggestion = CONTEXT_TOKEN_SUGGESTIONS[token.toLowerCase()];
+            //
+            // Every spelling in the imported map is a real authoring mistake, and
+            // each is a correct spelling *somewhere else* in the platform, which is
+            // exactly why authors reach for it: `current_user` is the RLS expression
+            // root, `{user_id}` is valid `titleFormat` field interpolation,
+            // `organization_id` is a real column name. The map only makes the runtime
+            // warning actionable; the authoring-time gate (`validateFilterTokens` in
+            // `@objectstack/lint`) is what actually prevents these from shipping.
+            const suggestion = NEAR_MISS_SUGGESTIONS[token.toLowerCase()];
             if (suggestion) {
                 warn(`Filter placeholder "{${token}}" is not a recognised token — did you mean ` +
                     `"{${suggestion}}"? It is sent to the server as a literal string and will ` +
@@ -150,7 +215,14 @@ export function resolveContextTokens(filter, scope = {}) {
         }
         if (Array.isArray(value))
             return value.map(walk);
+        // Only a PLAIN object (prototype `Object.prototype` or `null`) is a bag to
+        // walk. Anything else is a leaf, returned as the same instance: rebuilding
+        // a `Date` from its own keys — it has none — turned a comparand the spec
+        // admits (`ACCEPTED_FILTER_COMPARAND_TYPES`) into `{}` (objectui#10506).
         if (typeof value === 'object') {
+            const proto = Object.getPrototypeOf(value);
+            if (proto !== Object.prototype && proto !== null)
+                return value;
             const out = {};
             for (const k of Object.keys(value))
                 out[k] = walk(value[k]);
@@ -165,7 +237,7 @@ export function resolveContextTokens(filter, scope = {}) {
  * macros and context tokens — in one call.
  *
  * This is the function surfaces should call. Calling only one of the two
- * resolvers is the defect behind framework #3574: dashboard widgets called
+ * resolvers is the defect behind objectstack-ai/objectstack#3574: dashboard widgets called
  * `resolveDateMacros` alone, so `{today}` worked and `{current_user_id}`
  * silently did not.
  *

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

@@ -0,0 +1,61 @@
+/**
+ * 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 THIRD half of a view's field appetite (objectui#7179).
+ *
+ * A list view projects what it DISPLAYS — `$select` is built from `columns`.
+ * `predicate-fields.ts` covers the fields a view's PREDICATES read. This covers
+ * the fields it GROUPS BY, which is a third, independent source of demand: the
+ * spec's `grouping` block is a sibling of `columns`, not a subset of it, so a
+ * view may legitimately group by a field it never shows.
+ *
+ * ## Why it needed a fix rather than a gate
+ *
+ * `GroupingConfigSchema` accepts `grouping` with no matching column, and the
+ * neighbouring view kinds (kanban / gantt / timeline) already union their
+ * `groupByField` into the projection with no column required. Grouping by a
+ * field you do not want on screen is an ordinary thing to want. Refusing it at
+ * author time would make the grid the odd one out and reject working intent.
+ *
+ * ## The failure this closes
+ *
+ * With the grouping field absent from `$select` the server never returns it,
+ * so `useGroupedData` reads `undefined` on every row and `buildSegmentLabel`
+ * answers `(empty)` for all of them: ONE group holding every record, with no
+ * error, no warning and no empty state. It reads as "these records have no
+ * value for this field" — a plausible, wrong, actionable conclusion about the
+ * data rather than a visible bug in the view.
+ *
+ * ## ⛔ THE RESULT IS CANDIDATES, NOT VERIFIED FIELDS — the caller MUST gate it
+ *
+ * `GroupingFieldSchema.field` is a string that refuses a padded name
+ * (objectui#7347 — `grouping-field-padded-refused-7347.test.ts` in
+ * `@object-ui/types` pins it on every face declaring `grouping`; the trim below
+ * stays as defence for blocks that skipped that parse). Nothing in the schema
+ * requires it to name a field the object declares, and the whole premise of
+ * this harvest is that it has NOT been through column validation. Some backends
+ * answer an unknown `$select` key with an EMPTY RESULT SET rather than ignoring
+ * it — the cloud multi-tenant runtime does exactly that — so a single unknown
+ * grouping field put in the projection unguarded silently zeroes the whole
+ * list. That would convert this card's bug (one `(empty)` group holding every
+ * row) into a strictly worse one (no rows at all, still silent).
+ *
+ * So every caller intersects this result with the object's declared fields —
+ * {@link isProjectableField}, or the caller's equivalent known-field set —
+ * exactly as {@link collectPredicateFieldRefs}'s callers do, and for the same
+ * measured reason. Callers additionally FLS-gate it: a grouping field names a
+ * field just as capable of being denied as a column is, and the projection is
+ * what goes on the wire (objectui#6898).
+ *
+ * @param grouping - The view's `grouping` block in any authored state
+ *   (`undefined`, malformed, or the spec shape). Anything that is not an entry
+ *   carrying a non-empty string `field` contributes nothing, so a malformed
+ *   block yields an empty harvest instead of a plausible wrong name.
+ * @returns Grouping field names in first-seen order, deduplicated.
+ */
+export declare function collectGroupingFieldRefs(grouping: unknown): string[];

package/dist/utils/grouping-fields.js

@@ -0,0 +1,84 @@
+/**
+ * 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 THIRD half of a view's field appetite (objectui#7179).
+ *
+ * A list view projects what it DISPLAYS — `$select` is built from `columns`.
+ * `predicate-fields.ts` covers the fields a view's PREDICATES read. This covers
+ * the fields it GROUPS BY, which is a third, independent source of demand: the
+ * spec's `grouping` block is a sibling of `columns`, not a subset of it, so a
+ * view may legitimately group by a field it never shows.
+ *
+ * ## Why it needed a fix rather than a gate
+ *
+ * `GroupingConfigSchema` accepts `grouping` with no matching column, and the
+ * neighbouring view kinds (kanban / gantt / timeline) already union their
+ * `groupByField` into the projection with no column required. Grouping by a
+ * field you do not want on screen is an ordinary thing to want. Refusing it at
+ * author time would make the grid the odd one out and reject working intent.
+ *
+ * ## The failure this closes
+ *
+ * With the grouping field absent from `$select` the server never returns it,
+ * so `useGroupedData` reads `undefined` on every row and `buildSegmentLabel`
+ * answers `(empty)` for all of them: ONE group holding every record, with no
+ * error, no warning and no empty state. It reads as "these records have no
+ * value for this field" — a plausible, wrong, actionable conclusion about the
+ * data rather than a visible bug in the view.
+ *
+ * ## ⛔ THE RESULT IS CANDIDATES, NOT VERIFIED FIELDS — the caller MUST gate it
+ *
+ * `GroupingFieldSchema.field` is a string that refuses a padded name
+ * (objectui#7347 — `grouping-field-padded-refused-7347.test.ts` in
+ * `@object-ui/types` pins it on every face declaring `grouping`; the trim below
+ * stays as defence for blocks that skipped that parse). Nothing in the schema
+ * requires it to name a field the object declares, and the whole premise of
+ * this harvest is that it has NOT been through column validation. Some backends
+ * answer an unknown `$select` key with an EMPTY RESULT SET rather than ignoring
+ * it — the cloud multi-tenant runtime does exactly that — so a single unknown
+ * grouping field put in the projection unguarded silently zeroes the whole
+ * list. That would convert this card's bug (one `(empty)` group holding every
+ * row) into a strictly worse one (no rows at all, still silent).
+ *
+ * So every caller intersects this result with the object's declared fields —
+ * {@link isProjectableField}, or the caller's equivalent known-field set —
+ * exactly as {@link collectPredicateFieldRefs}'s callers do, and for the same
+ * measured reason. Callers additionally FLS-gate it: a grouping field names a
+ * field just as capable of being denied as a column is, and the projection is
+ * what goes on the wire (objectui#6898).
+ *
+ * @param grouping - The view's `grouping` block in any authored state
+ *   (`undefined`, malformed, or the spec shape). Anything that is not an entry
+ *   carrying a non-empty string `field` contributes nothing, so a malformed
+ *   block yields an empty harvest instead of a plausible wrong name.
+ * @returns Grouping field names in first-seen order, deduplicated.
+ */
+export function collectGroupingFieldRefs(grouping) {
+    const fields = grouping?.fields;
+    if (!Array.isArray(fields))
+        return [];
+    const out = [];
+    const seen = new Set();
+    for (const entry of fields) {
+        // The spec shape is `{ field, order, collapsed }`. A bare string is NOT
+        // accepted here even though it would be a natural shorthand: `grouping` is
+        // a `$strict` object schema in `@objectstack/spec`, so a bare string is
+        // off-spec metadata, and reading it anyway would be exactly the lenient
+        // renderer-side alias AGENTS.md #0.1 forbids — it fossilizes a second
+        // de-facto contract instead of having the producer rejected at publish.
+        const name = entry?.field;
+        if (typeof name !== 'string')
+            continue;
+        const trimmed = name.trim();
+        if (!trimmed || seen.has(trimmed))
+            continue;
+        seen.add(trimmed);
+        out.push(trimmed);
+    }
+    return out;
+}

package/dist/utils/managedBy.d.ts

@@ -19,7 +19,7 @@
  *
  * What is genuinely objectui's and keeps a local name:
  * {@link resolveEffectiveCrudAffordances} — the spec's object-level matrix
- * INTERSECTED with the server-resolved effective API operation set (#3391), so
+ * INTERSECTED with the server-resolved effective API operation set (objectstack#3391), so
  * the UI never offers a button the server would 405. The spec's function has
  * no such notion; naming ours after it was the misdescription this burn-down
  * removes.
@@ -125,7 +125,7 @@ export declare function userActionPredicates(v: UserActionOverride | undefined |
  *
  * @param obj The object schema (managedBy bucket + userActions overrides).
  * @param effectiveApiOperations OPTIONAL server-resolved effective API operation
- *   set for this object (from `/me/permissions` `apiOperations`, #3391). When
+ *   set for this object (from `/me/permissions` `apiOperations`, objectstack#3391). When
  *   provided, each affordance bit is ANDed with the corresponding API operation
  *   (create/import→create/import, edit→update, delete→delete, exportCsv→export),
  *   so the UI never shows a button the server would 405. Passing `undefined`
@@ -163,7 +163,7 @@ export declare function isSystemWritable(obj: SchemaLike | null | undefined): bo
  * object-level editability, so only the resolved boolean matters here.)
  *
  * @param effectiveApiOperations OPTIONAL server-resolved effective API operation
- *   set for this object (`/me/permissions` `apiOperations`, #3391/#3546). When
+ *   set for this object (`/me/permissions` `apiOperations`, objectstack#3391/objectstack#3546). When
  *   provided, inline-edit is additionally ANDed with the server allowing
  *   `update`, so a record page never offers double-click/pencil editing the
  *   server would 405. `undefined` (old backend / unrestricted) leaves the

package/dist/utils/managedBy.js

@@ -19,7 +19,7 @@
  *
  * What is genuinely objectui's and keeps a local name:
  * {@link resolveEffectiveCrudAffordances} — the spec's object-level matrix
- * INTERSECTED with the server-resolved effective API operation set (#3391), so
+ * INTERSECTED with the server-resolved effective API operation set (objectstack#3391), so
  * the UI never offers a button the server would 405. The spec's function has
  * no such notion; naming ours after it was the misdescription this burn-down
  * removes.
@@ -73,7 +73,7 @@ export function userActionPredicates(v) {
 }
 /**
  * The affordance-bit → server API-operation mapping used to intersect the
- * UI-intent affordances with the server's effective API operation set (#3391).
+ * UI-intent affordances with the server's effective API operation set (objectstack#3391).
  * This is the objectui end of the framework's `API_METHOD_DERIVATION` contract:
  * the button predicate is `affordance(op) ∧ effective.api(op)`.
  */
@@ -97,7 +97,7 @@ const AFFORDANCE_TO_API_OPERATION = {
  *
  * @param obj The object schema (managedBy bucket + userActions overrides).
  * @param effectiveApiOperations OPTIONAL server-resolved effective API operation
- *   set for this object (from `/me/permissions` `apiOperations`, #3391). When
+ *   set for this object (from `/me/permissions` `apiOperations`, objectstack#3391). When
  *   provided, each affordance bit is ANDed with the corresponding API operation
  *   (create/import→create/import, edit→update, delete→delete, exportCsv→export),
  *   so the UI never shows a button the server would 405. Passing `undefined`
@@ -113,7 +113,7 @@ export function resolveEffectiveCrudAffordances(obj, effectiveApiOperations) {
         managedBy: obj?.managedBy ?? undefined,
         userActions: (obj?.userActions ?? undefined),
     });
-    // [#3391] Intersect with the server's effective API operations when present.
+    // [objectstack#3391] Intersect with the server's effective API operations when present.
     // The frontend consumes the effective set the server hands down; it never
     // reads the raw `apiMethods` nor re-derives.
     if (Array.isArray(effectiveApiOperations)) {
@@ -159,7 +159,7 @@ export function isSystemWritable(obj) {
  * object-level editability, so only the resolved boolean matters here.)
  *
  * @param effectiveApiOperations OPTIONAL server-resolved effective API operation
- *   set for this object (`/me/permissions` `apiOperations`, #3391/#3546). When
+ *   set for this object (`/me/permissions` `apiOperations`, objectstack#3391/objectstack#3546). When
  *   provided, inline-edit is additionally ANDed with the server allowing
  *   `update`, so a record page never offers double-click/pencil editing the
  *   server would 405. `undefined` (old backend / unrestricted) leaves the

package/dist/utils/native-date-value.d.ts

@@ -0,0 +1,48 @@
+/**
+ * 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.
+ */
+/**
+ * Stored value → `<input type="date">` value (`YYYY-MM-DD`).
+ *
+ * A leading `YYYY-MM-DD` is passed through VERBATIM rather than re-parsed: a
+ * date-only string is parsed as UTC midnight by `new Date()`, so reading local
+ * calendar components back out of it shifts the day by one everywhere west of
+ * Greenwich. `2026-06-17` must stay June 17th in every zone.
+ */
+export declare function toDateInputValue(value: unknown): string;
+/**
+ * Stored value → `<input type="datetime-local">` value (`YYYY-MM-DDTHH:mm`),
+ * expressed in the viewer's local wall clock — the same instant the detail
+ * page shows, so opening the editor never appears to move the time.
+ *
+ * A value that is ALREADY a zone-less local datetime is truncated to minutes
+ * in place instead of being round-tripped through `Date`, which would
+ * reinterpret it and then re-render it, twice risking an off-by-a-zone shift.
+ */
+export declare function toDateTimeInputValue(value: unknown): string;
+/**
+ * `<input type="datetime-local">` value → stored value (ISO-8601, UTC).
+ *
+ * The control hands us a zone-less local wall clock; `new Date()` reads that
+ * form as local time, which is the inverse of what `toDateTimeInputValue`
+ * wrote — the pair is what keeps read and write on one basis.
+ *
+ * An unparseable string is returned untouched rather than blanked: dropping a
+ * value the user can see in the box would be a data loss dressed up as a fix.
+ */
+export declare function fromDateTimeInputValue(value: string): string;
+/**
+ * True when a stored value is written on a calendar day that does not exist
+ * (`2026-02-30`, `2026-02-30T10:00:00Z`, `2026-02-30T10:00+08:00`) — the day
+ * read AS WRITTEN from the leading `YYYY-MM-DD`, by the one judgement the read
+ * faces use (`isRealCalendarDate`). A parsed `Date` always names a real day,
+ * so the check can only be made before any conversion.
+ *
+ * Anything without a leading `YYYY-MM-DD` (a `Date`, a number, free text) is
+ * not this case and answers `false`.
+ */
+export declare function isImpossibleStoredDay(value: unknown): boolean;