test: pin the detail/form edit/delete gate to the server's effective operation set (#3546) (#2876)

os-zhuang · claude · web-flow · commit 51416172b741 · 2026-07-27T23:48:13.000+08:00
Adds the regression coverage objectui#2832 left open on issue objectstack#3546:
the detail header's Edit/Delete, the record-body inline-edit gate, and the
form's blanket field lock were pinned only by "existing suites still pass".

- app-shell RecordDetailView.headerActionGates (11 cases)
- plugin-detail record-details.effectiveOps (7 cases)
- plugin-form ObjectForm.effectiveOps (7 cases)

Each suite pins the two properties that make this an intersection and not a
union — a server grant never re-opens a bucket-closed affordance, and a
userActions opt-in never survives a server denial — plus the backward-compatible
undefined-effective-set fallback.

The header gate is extracted from the RecordDetailView body into an exported
resolveRecordHeaderActionGates() so it is reachable from a unit test, mirroring
ObjectView's defaultListColumnsFromObject. Behavior-preserving; not added to the
package's public export list. No changeset.

Verified by mutation: dropping the effective-ops argument at each of the three
call sites fails 14 of the new tests.

Co-Authored-By: Claude Opus 5 &lt;noreply@anthropic.com&gt;
diff --git a/packages/app-shell/src/views/RecordDetailView.headerActionGates.test.tsx b/packages/app-shell/src/views/RecordDetailView.headerActionGates.test.tsx
@@ -0,0 +1,130 @@
+/**
+ * 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.
+ */
+
+/**
+ * RecordDetailView — the detail header's Edit/Delete gate vs the server's
+ * effective API operation set (#3546).
+ *
+ * PR-4 (objectui#2823) intersected the LIST/TOOLBAR affordances with the
+ * server-resolved effective operation set (`/me/permissions` `apiOperations`).
+ * #3546 extends that intersection to the DETAIL surface: the synthesized
+ * `sys_edit` CTA (which also gates the record-body inline-edit session) and the
+ * `sys_delete` overflow item must never be offered for an operation the server
+ * would 405.
+ *
+ * These pin the resulting show/hide matrix, including the two properties that
+ * make this an INTERSECTION and not a union:
+ *   • a server grant never re-opens an affordance the lifecycle bucket closed;
+ *   • a permissive bucket default never survives a server denial.
+ * ...and the backward-compatible fallback: a missing effective set (unrestricted
+ * object / old backend / no PermissionProvider) leaves today's bucket +
+ * `userActions` decision untouched.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { resolveRecordHeaderActionGates } from './RecordDetailView';
+
+// `platform` is the permissive bucket — edit + delete both default open, so it
+// isolates the effective-set intersection as the only variable.
+const platform = { name: 'crm_lead', managedBy: 'platform' };
+
+describe('resolveRecordHeaderActionGates — effective API operations (#3546)', () => {
+  it('full-CRUD effective set → Edit and Delete both offered', () => {
+    expect(
+      resolveRecordHeaderActionGates(platform, ['get', 'list', 'create', 'update', 'delete']),
+    ).toEqual({ edit: true, delete: true });
+  });
+
+  it('read-only effective set → neither Edit nor Delete', () => {
+    expect(resolveRecordHeaderActionGates(platform, ['get', 'list'])).toEqual({
+      edit: false,
+      delete: false,
+    });
+  });
+
+  it('update-only effective set → Edit offered, Delete hidden', () => {
+    expect(resolveRecordHeaderActionGates(platform, ['get', 'list', 'update'])).toEqual({
+      edit: true,
+      delete: false,
+    });
+  });
+
+  it('delete-only effective set → Delete offered, Edit hidden', () => {
+    expect(resolveRecordHeaderActionGates(platform, ['get', 'list', 'delete'])).toEqual({
+      edit: false,
+      delete: true,
+    });
+  });
+
+  it('empty effective set ("expose nothing") → neither', () => {
+    expect(resolveRecordHeaderActionGates(platform, [])).toEqual({ edit: false, delete: false });
+  });
+
+  it('undefined effective set (unrestricted / old backend) → bucket wins, both offered', () => {
+    expect(resolveRecordHeaderActionGates(platform, undefined)).toEqual({
+      edit: true,
+      delete: true,
+    });
+    // Omitting the argument entirely must behave identically — this is the
+    // pre-#3546 call shape every non-permission-aware caller still uses.
+    expect(resolveRecordHeaderActionGates(platform)).toEqual({ edit: true, delete: true });
+  });
+
+  it('null effective set is treated as absent, not as an empty set', () => {
+    expect(resolveRecordHeaderActionGates(platform, null)).toEqual({ edit: true, delete: true });
+  });
+
+  // ── Intersection, never union ────────────────────────────────────────────
+  it('bucket-locked object stays locked even when the server allows update/delete', () => {
+    // `system` (engine-owned) closes edit + delete by default. A permissive
+    // server set must NOT re-open them — the server governs what it will
+    // accept, the bucket governs what the product offers.
+    expect(
+      resolveRecordHeaderActionGates({ name: 'sys_automation_run', managedBy: 'system' }, [
+        'get',
+        'list',
+        'create',
+        'update',
+        'delete',
+      ]),
+    ).toEqual({ edit: false, delete: false });
+  });
+
+  it('userActions opt-in still loses to a server denial', () => {
+    // sys_user opens `edit` via userActions (ADR-0103), but a caller whose
+    // effective set lacks `update` must not see the Edit CTA.
+    const sysUser = { name: 'sys_user', managedBy: 'better-auth', userActions: { edit: true } };
+    expect(resolveRecordHeaderActionGates(sysUser, ['get', 'list', 'update'])).toEqual({
+      edit: true,
+      delete: false,
+    });
+    expect(resolveRecordHeaderActionGates(sysUser, ['get', 'list'])).toEqual({
+      edit: false,
+      delete: false,
+    });
+  });
+
+  it('admin-editable `config` bucket intersects the same way', () => {
+    const webhook = { name: 'sys_webhook', managedBy: 'config' };
+    expect(resolveRecordHeaderActionGates(webhook, ['get', 'list', 'update', 'delete'])).toEqual({
+      edit: true,
+      delete: true,
+    });
+    expect(resolveRecordHeaderActionGates(webhook, ['get', 'list', 'update'])).toEqual({
+      edit: true,
+      delete: false,
+    });
+  });
+
+  it('a missing objectDef falls back to the platform default (no crash)', () => {
+    expect(resolveRecordHeaderActionGates(undefined, ['get', 'list', 'update'])).toEqual({
+      edit: true,
+      delete: false,
+    });
+  });
+});
diff --git a/packages/app-shell/src/views/RecordDetailView.tsx b/packages/app-shell/src/views/RecordDetailView.tsx
@@ -112,6 +112,34 @@ function isSecondaryField(fieldName: string, fieldDef: any): boolean {
   return SECONDARY_FIELD_NAME_HINTS.some((hint) => lc === hint || lc.endsWith(`_${hint}`));
 }
 
+/**
+ * Which system record-header affordances the record page may offer for this
+ * object — the primary `sys_edit` CTA (which also gates the record-body
+ * inline-edit session) and the `sys_delete` overflow item.
+ *
+ * [#3546] Each bit is the object's resolved CRUD affordance (lifecycle bucket +
+ * `userActions`) INTERSECTED with the server-resolved effective API operation
+ * set (`/me/permissions` `apiOperations`) — never a union. So a server grant can
+ * never re-open an affordance the object's bucket closed, and a permissive
+ * bucket default never survives the server denying `update` / `delete`. This is
+ * the detail-surface end of the same intersection the list/toolbar surface
+ * applies (objectui#2823). Passing `undefined` for `effectiveApiOperations`
+ * (unrestricted object / old backend / no `PermissionProvider`) leaves the
+ * bucket + `userActions` decision untouched — backward-compatible.
+ *
+ * Exported so the gate can be unit-tested directly: the record page itself is
+ * wired into routing, auth, presence and data fetching too deeply to render in
+ * a unit test, and this matrix is the part that must not regress. Same pattern
+ * as `defaultListColumnsFromObject` in `ObjectView`.
+ */
+export function resolveRecordHeaderActionGates(
+  objectDef: unknown,
+  effectiveApiOperations?: readonly string[] | null,
+): { edit: boolean; delete: boolean } {
+  const affordances = resolveCrudAffordances(objectDef as any, effectiveApiOperations);
+  return { edit: affordances.edit, delete: affordances.delete };
+}
+
 export function RecordDetailView({ dataSource, objects, onEdit, objectNameOverride, recordIdOverride, embedded }: RecordDetailViewProps) {
 
   const params = useParams<{
@@ -897,8 +925,8 @@ export function RecordDetailView({ dataSource, objects, onEdit, objectNameOverri
   const { can: canOnObject, isLoaded: permissionsLoaded, getObjectApiOperations } = usePermissions();
   // [#3546] Server-resolved effective API operation set for this object
   // (`/me/permissions` `apiOperations`). Threaded as the 2nd arg into
-  // `resolveCrudAffordances` for the detail header's Edit/Delete and the
-  // record-body inline-edit gate, so the detail surface never offers an
+  // `resolveRecordHeaderActionGates` for the detail header's Edit/Delete and
+  // the record-body inline-edit gate, so the detail surface never offers an
   // operation the server would 405 — the same intersection the list/toolbar
   // surface already applies (objectui#2823). `undefined` (unrestricted object
   // / old backend) leaves the bucket affordances untouched (backward-compatible).
@@ -1748,7 +1776,7 @@ export function RecordDetailView({ dataSource, objects, onEdit, objectNameOverri
   // menu permanently — Delete must never surface as an inline red button
   // just because an object has few actions.
   const synthSystemActions: ActionDef[] = (() => {
-    const affordances = resolveCrudAffordances(objectDef as any, effectiveApiOperations);
+    const affordances = resolveRecordHeaderActionGates(objectDef, effectiveApiOperations);
     const items: ActionDef[] = [];
     if (affordances.edit) {
       // Single primary Edit CTA → opens the full record form. Inline editing
@@ -1893,7 +1921,7 @@ export function RecordDetailView({ dataSource, objects, onEdit, objectNameOverri
             on backends that track the lock via approval requests only and
             never materialize an `approval_status` field (objectui#2618). */}
         <InlineEditProvider
-          canEdit={resolveCrudAffordances(objectDef as any, effectiveApiOperations).edit && !approvalLocked}
+          canEdit={resolveRecordHeaderActionGates(objectDef, effectiveApiOperations).edit && !approvalLocked}
           locked={approvalLocked}
           lockedReason={t('detail.lockedTooltip', {
             defaultValue: 'This record has a pending approval request; editing is locked',
diff --git a/packages/plugin-detail/src/renderers/__tests__/record-details.effectiveOps.test.tsx b/packages/plugin-detail/src/renderers/__tests__/record-details.effectiveOps.test.tsx
@@ -0,0 +1,130 @@
+/**
+ * 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.
+ */
+
+/**
+ * `record:details` — inline-edit vs the server's effective API operation set
+ * (#3546).
+ *
+ * The record BODY offers per-field editing through a double-click / hover
+ * pencil, gated by `isObjectInlineEditable`. #3546 intersects that gate with the
+ * server-resolved effective operation set (`/me/permissions` `apiOperations`),
+ * so a record page never offers inline editing the server would 405 on save.
+ *
+ * The renderer hands the resolved verdict to `<DetailView>` as
+ * `schema.inlineEdit`; these stub DetailView and assert that flag across the
+ * effective-set matrix — including that the intersection never becomes a union
+ * (a server `update` grant can't re-open a bucket-locked object) and that a
+ * missing effective set preserves today's behavior.
+ */
+
+import * as React from 'react';
+import { describe, it, expect, vi, beforeEach } from 'vitest';
+import { render, cleanup } from '@testing-library/react';
+
+const stub = {
+  /** Server-resolved effective API operations for the bound object. */
+  effectiveOps: undefined as string[] | undefined,
+  /** The bound object's schema (lifecycle bucket + userActions). */
+  objectSchema: { managedBy: 'platform' } as any,
+};
+
+vi.mock('@object-ui/react', () => ({
+  useRecordContext: () => ({
+    objectName: 'crm_lead',
+    recordId: 'rec_1',
+    data: { id: 'rec_1', name: 'Acme' },
+    dataSource: { update: async () => ({}) },
+    refresh: async () => {},
+    objectSchema: stub.objectSchema,
+  }),
+  useHighlightFieldNames: () => [] as string[],
+  useSafeFieldLabel: () => ({
+    sectionLabel: (_obj: string, _name: string, fallback: string) => fallback,
+  }),
+}));
+
+vi.mock('@object-ui/permissions', () => ({
+  usePermissions: () => ({
+    can: () => true,
+    getObjectApiOperations: () => stub.effectiveOps,
+  }),
+  useFieldPermissions: () => ({ readableFields: (names: string[]) => names }),
+}));
+
+// Capture the schema the renderer synthesizes — `inlineEdit` is the gate under
+// test. Stubbing DetailView also keeps the suite off the heavy field/registry
+// graph, which this behavior does not depend on.
+let captured: any = null;
+vi.mock('../../DetailView', () => ({
+  DetailView: (props: any) => {
+    captured = props?.schema;
+    return <div data-testid="detail-view" />;
+  },
+}));
+
+import { RecordDetailsRenderer } from '../record-details';
+
+/** Render the renderer and return the `inlineEdit` flag it resolved. */
+function inlineEditFor(schema: any = { fields: ['name'] }): boolean {
+  captured = null;
+  render(<RecordDetailsRenderer schema={schema} />);
+  return captured?.inlineEdit;
+}
+
+beforeEach(() => {
+  stub.effectiveOps = undefined;
+  stub.objectSchema = { managedBy: 'platform' };
+  captured = null;
+  cleanup();
+});
+
+describe('record:details — inline-edit vs effective API operations (#3546)', () => {
+  it('effective set WITH `update` → inline-edit offered', () => {
+    stub.effectiveOps = ['get', 'list', 'update'];
+    expect(inlineEditFor()).toBe(true);
+  });
+
+  it('effective set WITHOUT `update` → inline-edit withheld', () => {
+    // The #3546 behavior change: pre-fix this stayed `true` on a platform
+    // object and the body offered a pencil the server would 405 on save.
+    stub.effectiveOps = ['get', 'list'];
+    expect(inlineEditFor()).toBe(false);
+  });
+
+  it('empty effective set ("expose nothing") → inline-edit withheld', () => {
+    stub.effectiveOps = [];
+    expect(inlineEditFor()).toBe(false);
+  });
+
+  it('undefined effective set (unrestricted / old backend) → bucket wins, offered', () => {
+    stub.effectiveOps = undefined;
+    expect(inlineEditFor()).toBe(true);
+  });
+
+  it('bucket-locked object stays locked even when the server allows `update`', () => {
+    // Intersection, never union: an engine-owned object is not user-editable
+    // regardless of what the caller's effective set permits.
+    stub.objectSchema = { managedBy: 'system' };
+    stub.effectiveOps = ['get', 'list', 'create', 'update', 'delete'];
+    expect(inlineEditFor()).toBe(false);
+  });
+
+  it('userActions.edit opt-in still loses to a server denial', () => {
+    stub.objectSchema = { managedBy: 'better-auth', userActions: { edit: true } };
+    stub.effectiveOps = ['get', 'list', 'update'];
+    expect(inlineEditFor()).toBe(true);
+
+    stub.effectiveOps = ['get', 'list'];
+    expect(inlineEditFor()).toBe(false);
+  });
+
+  it('author opt-out (`inlineEdit: false`) still wins over a permissive server set', () => {
+    stub.effectiveOps = ['get', 'list', 'update'];
+    expect(inlineEditFor({ fields: ['name'], inlineEdit: false })).toBe(false);
+  });
+});
diff --git a/packages/plugin-form/src/ObjectForm.effectiveOps.test.tsx b/packages/plugin-form/src/ObjectForm.effectiveOps.test.tsx
