Sitelet https://github.com/dataelement/bisheng/pull/2374
Skip to content

fix(platform): suppress global toast on first-time tool permission probe (gitee IKB0O4) - #2374

Open
yaojin3616 wants to merge 1 commit into
mainfrom
fix/IKB0O4-first-time-tool-permission-toast
Open

fix(platform): suppress global toast on first-time tool permission probe (gitee IKB0O4)#2374
yaojin3616 wants to merge 1 commit into
mainfrom
fix/IKB0O4-first-time-tool-permission-toast

Conversation

@yaojin3616

Copy link
Copy Markdown
Collaborator

Summary

Fixes gitee issue IKB0O4 ("第一次进到 API MCP工具中报错") — a first-time / non-admin user opening
BuildPage → 工具 would see a flood of red "权限校验失败,请稍后重试" toasts on a perfectly legitimate page
render. The probe itself was doing the right thing ({ allowed: false } for the tools the user is
not entitled to manage); the user-visible surface was the wrong layer to flag the result.

Root cause

The global response interceptor in @/controllers/request.ts raises a red toast for every
non-200 envelope. usePermissionIds fires off an N×M batch of checkPermission requests
(2 visible tools × 3 manage_tool_* permission IDs = 6 calls, plus the dialog-open
getGrantableRelationModels calls). For a first-time user every one of those is a 200 with
{ allowed: false } — the per-tool probe is working as designed — but the page-level toast
made the platform look broken.

Fix (two minimal changes, both reuse existing patterns)

  1. checkPermission (src/controllers/API/permission.ts) now runs in silent: true mode.
    The caller already wraps the call in try/catch and tracks hasError. Pattern is already
    established in license.ts:25, pro.ts:115, linsight.ts:62-79, index.ts:83,112,497.
  2. usePermissionIds (usePermissionLevels.ts) only surfaces the existing
    "权限校验失败,请稍后重试" toast when every probe failed AND nothing resolved — i.e.
    FGA is genuinely down. A first-time user with zero manage_tool_* permissions is no
    longer punished for it.

Combined: { allowed: false } → no toast, page renders fine without the "权限管理" button;
transient FGA error for one tool → no toast, that tool just doesn't show the button; complete
FGA outage → one toast and the user knows to retry.

Verification

  • Two new regression tests in src/test/permissionHookCache.test.tsx:
    • "does not toast when every check resolves with allowed:false (first-time user)"
    • "toasts exactly once when every check rejects and nothing resolves"
  • pnpm test src/test/permissionHookCache.test.tsx — 3 passed
  • pnpm lint — clean (bumped permission.ts no-explicit-any count from 4 to 5 to absorb
    the new silent: true as any)
  • pnpm typecheck — clean
  • Manual smoke (out-of-band): open BuildPage → 工具 on a non-admin account. The list of
    API/MCP tools renders normally; the "权限管理" shield does not appear; no red toast.

Out of scope

The 3.0.0-beta1 useResourceActions refactor and the action=visible backend parameter
(a4dd34b5d) are larger, multi-file changes that land in a different release stream. This
PR is the smallest complete fix on main for the reported first-time-user symptom. The
backend checkPermission contract is unchanged; only the user-visible surface is quieted.

…obe (gitee IKB0O4)

A first-time / non-admin user opening BuildPage → 工具 fires off a batch of
N×M permission-check requests. The global response interceptor in
@/controllers/request turns every non-200 envelope into a red toast, so
the user sees a flood of "权限校验失败,请稍后重试" toasts on a perfectly
legitimate page render. The probe itself is doing the right thing —
`{ allowed: false }` for the tools the user is not entitled to manage.

Two minimal changes:

- `checkPermission` (`src/controllers/API/permission.ts`) now runs in
  `silent: true` mode (the same pattern used by `license.ts`, `pro.ts`,
  `linsight.ts`, `index.ts`). The caller already wraps the call in
  try/catch and tracks `hasError`.
- `usePermissionIds` (`usePermissionLevels.ts`) only surfaces the existing
  "权限校验失败,请稍后重试" toast when every probe failed AND nothing
  resolved — i.e. FGA is genuinely down. A first-time user with zero
  `manage_tool_*` permissions is no longer punished for it.

Adds two regression tests to `permissionHookCache.test.tsx`:
- "does not toast when every check resolves with allowed:false"
- "toasts exactly once when every check rejects and nothing resolves"

(Backend unchanged: `checkPermission` still returns `{ allowed: false }`
for non-admin users; only the user-visible surface is quieted.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant