Skip to content

fix(plugin-list,plugin-grid): list empty state tells no-access and "mine" apart from no records - #25987

Merged
objectstack-fleet[bot] merged 6 commits into
mainfrom
claude/project-thread-lr711r
Oct 26, 2026
Merged

objectstack-fleet[bot] merged 6 commits into
mainfrom
claude/project-thread-lr711r

Conversation

@objectstack-fleet

Copy link
Copy Markdown
Contributor

Requested by Steve · project thread
Fixes #25898

Clause-②: no
Metadata-protocol: none

What changes

An empty list chose its copy from the user's query and the view's declared filter alone. Two cases from the card's table were wrong:

  • No filter, caller may not create. A member who may read none of an object's records and holds no create grant was told "Nothing here yet / Create your first record to get started." beside no Create button. Once the permission answer has loaded, a caller without the listNew verdict of the affordance-to-grant map (managed-object policy, effective API operations and the caller's create grant, the same verdict the page's own New reads) now gets "No records you can see / There are no records here that you have access to. If you expected to see some, ask your administrator for access." The add-record action is not drawn for that caller, even on a view whose addRecord is enabled.
  • A "my" view. When the view's declared filter names the signed-in user (a comparand equal to the caller's id, which is what a host-resolved {current_user_id} becomes, or the placeholder itself), the empty state reads "Nothing of yours yet / This view lists only records that are yours, and you don't have any yet." instead of "No records match this view's filter.", with the add-record action only under the create grant.

Unchanged: the first-run copy and action for a caller who may create, the user-query copy, the plain view-filter copy, an authored emptyState (it still wins), the 403 error panel (its own state, untouched), and every surface with no permission provider mounted (fail-open, as the affordance map is).

Where it lands, following the card's measured producers:

  • ListEmptyState (plugin-list, module-internal) makes the decision: two new optional props, baseFilterNamesCurrentUser and mayCreate (false is a known denial, absent is "not known"), and the exported helper filterNamesCurrentUser.
  • ListView (grid and gallery visualizations) passes both from the empty-state call site: the resolved declared filter against the session scope's currentUserId, and resolveAffordance('listNew', …) once usePermissions().isLoaded.
  • ObjectGallery (standalone) passes the same two facts.
  • ObjectGrid's default empty state makes the same decision in its own empty-state region (it draws no add-record action, as before). plugin-grid and plugin-list do not depend on each other, so the filter walk is restated there in a few lines.
  • @object-ui/i18n: list.ownedNoneTitle, list.ownedNoneMessage, list.noneVisibleTitle, list.noneVisibleMessage in all ten packs, and in the two in-code English fallback tables (LIST_DEFAULT_TRANSLATIONS, ObjectGrid's).
  • scripts/sdui-manifest.record.json: the registry-source hash re-recorded by node scripts/gen-sdui-manifest-node.mjs, which every ui/packages/** source change requires (check-sdui-manifest); the manifest itself is byte-identical.

The copy is generic rather than naming the object ("你没有可查看的工单" in the card) so it needs no plural forms across ten locales; the zh pack reads 「没有你可查看的记录」 and 「你还没有负责的记录」.

Tests

At head 8878ebe8 (implementation unchanged since be788ede; later commits are the main merge and the manifest record):

  • New: ListView.emptyStateAccess-25898.test.tsx (9), ObjectGallery.emptyStateAccess-25898.test.tsx (4), ObjectGrid.emptyStateAccess-25898.test.tsx (5), through the real MePermissionsProvider and FilterScopeProvider: 3 files, 18 tests passed.
  • Reverse verification: the four source files and the locale packs restored to the base commit 38050ced with the tests kept: 11 failed / 7 passed, exactly the predicted split (every no-access, "mine" and zh row red; the create-grant, no-provider and plain-filter controls green). Restored from HEAD afterwards, git diff HEAD empty.
  • vitest run packages/plugin-list/ packages/plugin-grid/ packages/i18n/ packages/plugin-form/src/affordanceGrantMap-12082.test.tsx (the affordance census included): 498 files passed, 5253 tests passed, 13 skipped.
  • type-check for @object-ui/plugin-list, @object-ui/plugin-grid, @object-ui/i18n: clean.
  • node scripts/pm/dispatch-gates.mjs --commands: 47 derived families run locally, all exit 0 (check-sdui-manifest exited 1 before the record was regenerated and 0 after); --ran reconciliation: 47 accounted, 0 not measured.

Acceptance notes

  • The {current_user_id} walk is shape-agnostic: any string comparand equal to the caller's id counts, so a filter like owner = me OR status = open also reads "Nothing of yours yet". Views of that shape are rare; the copy is still true of the caller's own records.
  • The toolbar's add-record buttons (top and bottom) still follow addRecord.enabled alone inside ListView; the console host already withholds addRecord without the create grant, so only a non-console host could show them to a caller without the grant. Left out of this card's empty-state scope; noted, not filed.
  • A shared home for the decision in @object-ui/core would let ObjectGrid and ListEmptyState share one function; core is outside this card's claimed surface, so the grid restates it.

Generated by Claude Code

…ine" apart

An empty list without a filter now reads "No records you can see" for a
caller known not to hold the create grant (the listNew affordance row), and
never draws the add-record action for that caller. A view whose declared
filter names the signed-in user reads "Nothing of yours yet" instead of
"No records match this view's filter". ListView, the standalone
ObjectGallery and ObjectGrid's default empty state all decide the same way.
Four list.* keys added to the ten locale packs.

Claude-Session: https://claude.ai/code/session_01RYq63NT6L4eGmQNvE9e7D8
Co-authored-by: Claude <noreply@anthropic.com>
@objectstack-fleet

Copy link
Copy Markdown
Contributor Author

席位核对 · ACCEPT · seat domain:ui#1 · 2026-10-26T08:23Z

Head 8878ebe80ccf (read from the PR object).

  • Shape. Draft on main; Fixes #25898; Clause-②: no, Metadata-protocol: none; changeset .changeset/25898-list-empty-state-access.md in the root .changeset/ (patch, plugin-list + plugin-grid + i18n).
  • Checks pinned to the head. 61 named check runs, latest per name: 54 success, 7 skipped, 0 failing, 0 pending. Lint & Repo Gates, TypeScript Type Check, Test UI 16/16, Type Check UI all success.
  • Governed surface. check-governed-merges.mjs --pr 25987: 0 of 19 paths governed.
  • Changeset against the diff. ListEmptyState gains baseFilterNamesCurrentUser and mayCreate; the user's own query still wins, then a filter naming the caller ("Nothing of yours yet"), then another declared filter, then, with no filter and a KNOWN listNew denial, "No records you can see"; first-run otherwise. A known denial withholds the add-record action even when onAddRecord is passed. mayCreate is asked only after the permission answer has loaded, so an unloaded provider keeps today's copy. ObjectGrid's default empty state applies the same order. Each sentence matches the code.
  • Serial constraint held. ObjectGrid.tsx changes only the default-empty-state copy and its translation defaults, not the group-header region fix(plugin-grid): order a grouped grid's groups by the level's orderBy #25977 changed.
  • Known limit, not blocking. filterNamesCurrentUser is shape-agnostic and does not read the operator, so a filter that EXCLUDES the caller (owner != current user) also reads "Nothing of yours yet". The changeset scopes the feature to "owner equals the current user", and no shipped view is known to use the inverse. If one turns up, it is a card, not a hold on this PR.
  • Out-of-surface file. scripts/sdui-manifest.record.json: the derived hash only.

⚠️ Merge order: #25978 and #25984 append to the same ten locale packs, and #25977 / #25978 / #25984 move the same manifest-record line. Whichever lands later merges origin/main and regenerates the record.

Landing: ready + auto-merge through the relay.

@github-actions

Copy link
Copy Markdown
Contributor

⛔ merge queue 构建失败 — 先分诊,再决定要不要重排

队列构建 40317813492 红了。队列跑的是全量套件(PR 侧 CI 只跑 affected 子集),
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

分类:failure —— 按下面的日志分诊。

失败的 job(日志抽取,best effort):

  • Build Core — 失败步骤: Build packages (excluding docs)(日志不可读,点进 job 看)

  • Build & E2E UI — 失败步骤: Build the Console for E2E

    ✗ Build failed in 5.46s
    
  • Type Check UI — 失败步骤: Run type-check over the ui packages(日志不可读,点进 job 看)

  • Lint UI — 失败步骤: Build every ui package the gates below read(日志不可读,点进 job 看)

↳ 失败原因 是判读的关键:超时(Test timed out in … / Hook timed out in …)多半是负载/时序,不是本 PR 的回归;
断言(AssertionError: …)才指向真实的行为改变。两者的 FAIL 行长得一模一样,只有这一行能区分。

⚠️ 断言这一侧有一类例外,判据是断言在测什么,不是它是不是 AssertionError。 断言的对象是产品行为(一个值、一个形状、一次拒收)⇒ 照上面读:真实的行为改变,去查,⛔ 不要重排掉;
断言的对象是这次实验自身的有效性前提(跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件)⇒ 它跟超时是同一类,同样对负载敏感,重排一次是合法的判别手段。
识别是机械的:断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为(真回归);
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提:它守护的那条不变式当时是绿的,同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量,仍然是时间测量。(⛔ 这只改「怎么读一次红」,不改「哪些测试可以重排」——后者由别处管。)

跨 PR 相同签名(24h,按失败测试文件聚合):

  • ⚠️ 本次没有可用的聚合签名(日志里没有能解析出测试文件名的 FAIL 行)—— 这不是「没有同签名的其他 PR」,是这一轮没测到。跨 PR 聚合本次不可用,请手工比对其他 PR 的同类评论。
  • ⚠️ 24h 评论账本没读完(超过 5 页仍未读到窗口尽头),所以上面的「不同 PR 数」是下界,不是全量。

历史信号:

  • 本 PR 过去 24h 无队列失败记录(首次)。
  • 过去 24h 队列共有 28 个失败构建(不含本次)。

分诊清单:

  1. 失败测试在本 PR 改动的包里 → 真回归,修 PR。
  2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」;已有汇总 issue ⇒ flaky/环境问题实锤,去那张 issue 上谈,修好前重排只会再烧一轮全队列。
  3. 两者都不是 → 可能与同组 PR 语义冲突;等前面的 PR 落地或失败出队后再重排一次即可,不要连续重排。

Generated by Claude Code · merge-queue-triage workflow (#4859)

Merged via the queue into main with commit cc378e9 Oct 26, 2026
61 checks passed
@objectstack-fleet
objectstack-fleet Bot deleted the claude/project-thread-lr711r branch October 26, 2026 12:21
os-elon-musk pushed a commit that referenced this pull request Oct 26, 2026
…lugin-grid, plugin-list)

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SMJGPXxFBpbgAgXdnsXKVS
os-zhuang pushed a commit that referenced this pull request Oct 26, 2026
… different packages stop conflicting (#26120)

<!-- claude-projects-attribution: {"github_login":"os-elon-musk"} -->
_Requested by **Elon** · [project
thread](https://claude.ai/code/project/chan_01WedDzV26nniwxv7jC88B9D?thread=cmsg_01WedDzV26nniwxv7jC88B9DPXV532seCFDcrkAJybGzsf)_

Fixes #26051

Clause-②: no
Metadata-protocol: none

Part of the p1 merge-queue backlog work (#26074). Dispatched by seat
`domain:devx#1` (#6023), claim 6415558140, card-thread session
`session_01SMJGPXxFBpbgAgXdnsXKVS`.

## What changes

`scripts/sdui-manifest.record.json` carried ONE
`inTree.registrySourcesSha256` over the `src/` of all 27 ui registry
packages, so any two ui PRs that touched any registry package conflicted
on that line. Now:

- **One record per registry package**, one file each, one line each:
`scripts/sdui-manifest.sources/PACKAGE.json` =
`{"package","sources","sha256","manifestSha256"}` (the package's own
`src/` digest, its file count, and the sha256 of the artefact it was
verified against). 27 files.
- **The shared record** (`scripts/sdui-manifest.record.json`, same path)
keeps only what describes the artefact: `sha256`, `components`,
`generatedAt`, and `inTree` = `modulesRoot`, `objectuiWorkspaceVersion`,
`registryRecords` (the directory). The retired `registryPackages` /
`registrySources` / `registrySourcesSha256` are refused if they
reappear.
- **The reached package set** is the set of record files: a reached
package with no record (new package, new dependency edge into the
registry, deleted record) is RED; a record the registry no longer
reaches (removed package, dropped edge) is RED.
- `sdui.manifest.json` is byte-identical (sha256 `1f6e1ccb925a…`, 106
components).

`lint.yml`'s command line (`node scripts/check-sdui-manifest.mjs
--self-test && node scripts/check-sdui-manifest.mjs`) is unchanged and
keeps working. No `.github/**` or `ui/.github/**` edit.

## Measured first (Ask 1): own `src/` per package, not
dependency-inclusive

Tree: objectstack `0a6948210c` (base), 27 reached packages, 922 non-test
sources.

**Detection is the same as one digest over the set.** Any edit under any
reached package's `src/` moves exactly that package's digest, so a
single PR's edit is caught exactly as before; a dependency's edit is
caught through the dependency's own record. Dependency-inclusive digests
add no single-PR detection. They would only add conflicts, and at this
cost (records a `src/` edit would touch):

| package edited | own `src/` (this PR) | dependency-inclusive |
|:--|:-:|:-:|
| `types` | 1 | 25 |
| `core` | 1 | 21 |
| `data-objectstack`, `i18n` | 1 | 19 |
| `react`, `react-runtime`, `sdui-parser` | 1 | 18 |
| `components` | 1 | 17 |
| `fields` | 1 | 14 |
| `plugin-detail` | 1 | 10 |
| `plugin-form`, `plugin-grid` | 1 | 2 |
| the other 11 plugins | 1 | 1 |

**Merge experiment, real tree, `git merge-tree --write-tree` (no merge
driver routes these paths; `git check-attr merge` = unspecified, so this
is GitHub's answer):** each branch appends a comment to one `src/` file
and runs the generator.

| pair | before (single digest, on `0a6948210c`) | after (this PR, on
`a8114011`) |
|:--|:--|:--|
| `plugin-grid/src/FormulaBar.tsx` × `plugin-form/src/DrawerForm.tsx` |
exit 1, CONFLICT in `scripts/sdui-manifest.record.json` | exit 0, clean;
the merged tree passes `check-sdui-manifest` (exit 0) |
| `plugin-grid/src/FormulaBar.tsx` × `plugin-grid/src/ObjectGrid.tsx` |
(conflicts) | exit 1, CONFLICT in
`scripts/sdui-manifest.sources/plugin-grid.json` only, by design |

**The open ui PRs today** (registry packages each changes, non-test
`src/` only; none changes `sdui.manifest.json`): #25987 i18n,
plugin-grid, plugin-list · #25998 plugin-detail · #26040 components,
i18n · #26045 i18n · #26027 plugin-dashboard · #26030 plugin-grid ·
#26033 core, plugin-form, plugin-grid · #26042 plugin-form · #26044 i18n
· #26048 i18n, plugin-map · #26050 fields, plugin-grid · #26062 fields.
Under the single digest all 12 conflict pairwise (12 serial landings).
Under this layout they conflict only within a shared package; the
largest group is `i18n` (5 PRs), so they can land in 5 rounds, e.g.
{#25987, #25998, #26027, #26042, #26062} → {#26040, #26030} → {#26045,
#26033} → {#26044, #26050} → {#26048}, assuming no source-level
conflicts between them.

## The check (Ask 2)

`checkTreeWithoutPin` compares each reached package's digest with its
own record and names every stale package (`ui/packages/plugin-grid: now
38 file(s) sha256 …, recorded …`), every unrecorded package, every
record the registry no longer reaches, every record verified against
another artefact, and every malformed record, then prints the one
command: `node scripts/gen-sdui-manifest-node.mjs`. The pin mode
(`.objectui-sha` present) is untouched.

**Why `manifestSha256` is in every package record, and why one line:** a
PR that changes the artefact re-records every package against the new
sha256, so it still conflicts with every in-flight registry PR, which
must regenerate on the merged tree (that is today's behaviour, kept for
the case where it matters). Two PRs on the same package touch the same
line and conflict. One line per file guarantees git cannot merge a
digest from one side with an artefact sha256 from the other; a record
that is not in the producer's one-line form is RED.

**What this does not force, stated rather than implied:** two PRs on
different packages that each leave the artefact unchanged, where only
their combination would change it, land without any run seeing the
combination. Under the single digest their textual conflict forced that
run. Here the next regeneration of any registry package sees the
combination. Dependency-inclusive digests would close this only along
import edges (not between siblings that interact through
`ComponentRegistry`), at the fan-out above. No stale or missing registry
source passes: every source edit still reds until regenerated, and every
package added to or removed from the reached set still reds.

## Self-test (Ask 3)

29 rows (was 22), roster and floor updated. New or changed in-tree rows:
a staged edit to one package is RED naming that package and NOT naming
`plugin-form` or `core`; a new package the registry reaches; a new
workspace edge (now names `ui/packages/unrelated`); a removed package
(names `scripts/sdui-manifest.sources/types.json`); a deleted package
record; a record verified against another artefact; a record out of its
one-line form; a record from the single-digest layout; and the producer
re-recording only the moved package (it back-dates the shared record
first, so a producer that stamps today's date reds the row).

Ablations, one at a time through `scripts/ablation-replace.mjs`, each
restored with `git diff HEAD` empty:

| guard removed | self-test |
|:--|:--|
| the other-artefact comparison (gate) | exit 1, row "a package record
verified against another artefact is RED" expected RED got GREEN |
| the one-line form comparison (gate) | exit 1, row "a package record
out of its one-line form is RED" |
| the unreached-record list (gate) | exit 1, row "a removed registry
package is RED naming its record" |
| the `generatedAt` carry (producer) | exit 1, row "the producer
re-records only the package whose sources moved": the second run changed
the shared record too |
| the per-package record write (producer) | exit 1, the two producer
rows |

## The generator (Ask 4)

It re-records only the packages whose line changed and leaves the others
byte-identical; it removes a record the registry no longer reaches; it
prints which packages it re-recorded. The shared record moves only with
the artefact: `generatedAt` and the provenance version are carried while
the artefact's sha256 is unchanged (the same rule the pin-keyed fields
already follow), so a regeneration on another day no longer moves a
shared line.

**It still builds, and why:** the build plus the enumeration is the only
oracle that says whether `sdui.manifest.json` moved. A record written
without it would stamp a current digest on a manifest no run checked,
which is the narrowing this card forbids. The 8 minutes is a cold turbo
cache, not the build of one package. Measured on `0a6948210c`, one
container, no remote cache (`TURBO_TOKEN` unset):

| run | wall | turbo |
|:--|:-:|:--|
| cold | 8m49s | 0 of 63 cached, 8m43s |
| nothing moved | 6s | 63 of 63 cached |
| one edit under `plugin-grid/src` | 33s | 61 of 63 cached, 27s |
| one edit under `core/src` | 2m50s | 41 of 63 cached, 2m44s |

## Readers moved (Ask 5)

- `docs/releases-maintenance.md`: the regenerate section describes the
per-package records, the re-record rule and which PRs still conflict.
- `scripts/check-changeset-no-major.mjs`: the "measured out" comment,
the real-build assertion (neither record is shipped) and the
records-only control now cover `scripts/sdui-manifest.sources/`. Its
`--self-test` passes (456 assertions).
- `scripts/ui-import/README.md` is not edited: line 140 records what the
cutover's step 4 wrote at the time, and that file still exists at that
path.
- `git grep -n "sdui-manifest.record"` outside CHANGELOGs: only the two
scripts, the docs page, `check-changeset-no-major.mjs` and that
historical README line. `git grep registrySourcesSha256`: only the
retired-field list and its self-test row.

## After this lands: what an in-flight ui PR does (once)

A ui PR whose branch re-recorded the old single digest conflicts once on
`scripts/sdui-manifest.record.json`:

```sh
git merge origin/main                                   # conflict in scripts/sdui-manifest.record.json
git checkout --theirs scripts/sdui-manifest.record.json  # take main's layout
node scripts/gen-sdui-manifest-node.mjs                  # re-records only this PR's package(s)
git add scripts/sdui-manifest.record.json scripts/sdui-manifest.sources sdui.manifest.json
git commit
```

After that, PRs on different registry packages no longer conflict with
each other on the record.

## Gates

Local, on `a8114011` (derived with `node scripts/pm/dispatch-gates.mjs
--commands`): 39 of the 40 derived families exit 0, including `node
scripts/check-sdui-manifest.mjs --self-test` (29 cases) and `node
scripts/check-sdui-manifest.mjs`, `node
scripts/check-changeset-no-major.mjs --self-test` and `--base
origin/main`, `pnpm check:nul-bytes`, `pnpm check:watch-hint-literal`,
`pnpm check:required-contexts`, `pnpm check:doc-authoring` and `pnpm
--filter @objectstack/lint run check:doc-formula-expressions` (after the
lint closure build). `pnpm check:pm-dispatch-gates` was still running
when this PR opened; its reading goes into the report comment on #26051,
and CI runs it in Lint & Repo Gates.

CI on the PR's check-runs: pending at the time of writing; the seat
reads them.

Changeset: none, `skip-changeset`. The diff touches only root `scripts/`
(private), `docs/` and the records; `sdui.manifest.json` is
byte-identical and neither record is copied into
`packages/console/dist/` (the `check-changeset-no-major` real-build
assertion above).

Not Tier H: no governed path (`git diff --name-only` has no `.github/`,
`.claude/`, `docs/adr/`, `skills/`, `AGENTS.md`, `CLAUDE.md`).

## Acceptance notes

- `i18n` is the hot package: 5 of the 12 open ui PRs touch its `src/`,
so they still serialize on `scripts/sdui-manifest.sources/i18n.json`.
Whether locale data belongs in the digest at all is a narrowing question
(it would let a source change pass unregenerated), not something this PR
decides.
- The cold-cache cost of a regeneration (8m43s here) is a
fresh-container property; card threads run with no turbo remote cache.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01SMJGPXxFBpbgAgXdnsXKVS)_

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/l tooling

Projects

None yet

2 participants