fix(platform): suppress global toast on first-time tool permission probe (gitee IKB0O4) - #2374
Open
yaojin3616 wants to merge 1 commit into
Open
fix(platform): suppress global toast on first-time tool permission probe (gitee IKB0O4)#2374yaojin3616 wants to merge 1 commit into
yaojin3616 wants to merge 1 commit into
Conversation
…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.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes gitee issue
IKB0O4("第一次进到 API MCP工具中报错") — a first-time / non-admin user openingBuildPage → 工具 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 isnot entitled to manage); the user-visible surface was the wrong layer to flag the result.
Root cause
The global response interceptor in
@/controllers/request.tsraises a red toast for everynon-200 envelope.
usePermissionIdsfires off an N×M batch ofcheckPermissionrequests(2 visible tools × 3
manage_tool_*permission IDs = 6 calls, plus the dialog-opengetGrantableRelationModelscalls). 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 toastmade the platform look broken.
Fix (two minimal changes, both reuse existing patterns)
checkPermission(src/controllers/API/permission.ts) now runs insilent: truemode.The caller already wraps the call in
try/catchand trackshasError. Pattern is alreadyestablished in
license.ts:25,pro.ts:115,linsight.ts:62-79,index.ts:83,112,497.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 nolonger 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
src/test/permissionHookCache.test.tsx:pnpm test src/test/permissionHookCache.test.tsx— 3 passedpnpm lint— clean (bumpedpermission.tsno-explicit-anycount from 4 to 5 to absorbthe new
silent: true as any)pnpm typecheck— cleanAPI/MCP tools renders normally; the "权限管理" shield does not appear; no red toast.
Out of scope
The 3.0.0-beta1
useResourceActionsrefactor and theaction=visiblebackend parameter(
a4dd34b5d) are larger, multi-file changes that land in a different release stream. ThisPR is the smallest complete fix on
mainfor the reported first-time-user symptom. Thebackend
checkPermissioncontract is unchanged; only the user-visible surface is quieted.