fix(plugin-list): offer the In a queue toggle only when the organization has a queue - #28889

Fixes #28428

Clause-②: yes (widening)
Metadata-protocol: none

维护者速读

• 改了什么:列表工具栏的「在队列中」开关现在只在两个条件都成立时出现:对象带平台注入的 queue 字段,且当前会话的 /auth/me/permissions 回答 hasAnyQueue: true(组织至少有一个队列)。@object-ui/permissions 的上下文新增一个可选成员 hasAnyQueue,把服务端这个布尔值原样传下去。
• 为什么改:平台给每个归属用户的对象都注入 queue 字段,所以没有任何队列的组织(如 app-crm、HotCRM)每个列表都显示这个开关,点了永远是空列表。按 List toolbar: offer the "In a queue" toggle only when the organization has at least one queue — today every owned object shows it, and in an app with no queues it always returns an empty list #28428 的裁定 A,服务端已在 Session payload: the console learns once per session whether the caller's organization has at least one ownership queue (declared or sys_queue), with no widening of member read on sys_queue #28508 提供该布尔值。
• 风险与回滚:会话没有这个答案时(没有权限提供者、基于角色的提供者、匿名会话)开关隐藏;控制台的提供者在答案到达前不渲染列表,所以控制台里不会出现"加载中"的状态。服务端的队列行为(认领、释放、读取规则)不变。回滚即还原本 PR,无数据或协议变更。
• 先看:ui/packages/plugin-list/src/ListView.tsx(queueFilterOffered)、ui/packages/permissions/src/MePermissionsProvider.tsx(hasAnyQueue)、ui/packages/permissions/src/PermissionContext.ts。
• 两分钟验证:cd ui && pnpm exec vitest run packages/plugin-list/src/__tests__/ListView.queueSittingFilter-25769.test.tsx packages/permissions/src/__tests__/hasAnyQueue-28428.test.tsx,预期 18 个用例全绿。
• 需要你做的:无,席位落地。

What changes

• @object-ui/permissions: PermissionContextValue gains one optional member, hasAnyQueue?: boolean. MePermissionsProvider sets it from the authenticated /auth/me/permissions answer (Session payload: the console learns once per session whether the caller's organization has at least one ownership queue (declared or sys_queue), with no widening of member read on sys_queue #28508). It is undefined with no answer: the anonymous answer, the role-based PermissionProvider, and no provider at all (usePermissions' no-provider literal). ServerReadScope and RecordFieldAccessScope spread their parent, so they forward it unchanged.
• @object-ui/plugin-list: queueFilterOffered is now hasAnyQueue === true && objectHasOwnershipQueue(objectDef). The flag rides the permissions answer the console already holds, so opening a list reads no queue list and sends no new request.
• Unknown flag = hidden (claim amendment 6567840348). Under the console, MePermissionsProvider renders its loading fallback until the payload arrives, so a list never sees a pending flag there. Elsewhere (no provider, the role-based provider, an anonymous session) nothing can show a queue exists, so the toggle stays hidden.
• Turning the toggle on filters exactly as before. Nothing on the server changes.

Why

Route A ruling 6553134732 on #28428: offer the toggle when the object carries the queue field AND the session's has-queues boolean is true. In an organization with no queue, the toggle could only return an empty list.

Tests

• ListView.queueSittingFilter-25769.test.tsx: the existing cases now mount under a session double (MePermissionsProvider with hasAnyQueue: true) and still pass. New cases: no queue gives no toggle even on an object with the injected column; one queue gives the toggle; an unknown answer (no provider, anonymous) gives no toggle; a list mount makes the same data-source calls with and without a queue, every find targets the listed object, and fetch is never called.
• New hasAnyQueue-28428.test.tsx in @object-ui/permissions: the truth table (served true and false, anonymous, forwarded through ServerReadScope, role-based provider, no provider).
• Ablations, each run through scripts/ablation-replace.mjs with the blob restored to HEAD afterwards:
  • Gate removed ((hasAnyQueue === true || true) && …): 2 red, "no queue" and "unknown answer".
  • Provider member removed (hasAnyQueue: undefined): 3 red, served true, served false, scope forwarding.

Acceptance notes

Measured on a production console build (turbo run build, pnpm console:build), pnpm dev:crm -- --fresh, admin, at head c0b35cd6:

• crm_account serves the injected queue column (system: true, hidden), so the old rule would have shown the toggle there.
• Pressing the toggle with one queue sends GET /api/v1/data/crm_account?…&filter=["and",["owner_id","is_empty",true],["queue","is_not_empty",true]], the same filter as before.
• Network: a list load made 31 or 32 API requests in both states, over two runs each. The distinct endpoint sets were identical. The one-request difference is a sys_user_preference PATCH that comes and goes with timing in either state. No request in any run named a queue.
• Acceptance 1 says HotCRM too. HotCRM declares no queue (card reading), so it gets hasAnyQueue: false and the same result. It was not run here: it lives in another repository.
• Screenshots are in the project files under issue-28428/.

Verification

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (packages/spec not touched.)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint is CI's run.
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: not applicable.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English (the 维护者速读 section is the Chinese summary the repo asks for).

🤖 Generated with Claude Code

https://claude.ai/code/session_01QsR2jUddMTB1CyxjzoKGxi

Generated by Claude Code