fix(frontend): guard execution channel query by permission#1770
Conversation
Avoid requesting request execution channel fields when users only have request log access. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the GraphQL requests query builder to conditionally include channel fields in both request and execution selections based on canViewChannels.
Changes:
- Renamed the request-level channel fields variable for clarity (
channelFields→requestChannelFields). - Added a separate conditional fragment for execution-level channel fields (
executionChannelFields). - Simplified execution node selection by interpolating the channel fragment instead of inlining it.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const requestChannelFields = permissions.canViewChannels | ||
| ? ` | ||
| channel { | ||
| id | ||
| name | ||
| }` | ||
| : ''; | ||
|
|
||
| const executionChannelFields = permissions.canViewChannels | ||
| ? ` | ||
| channel { | ||
| id | ||
| name | ||
| }` | ||
| : ''; |
Greptile SummaryThis PR fixes a permission error on the
Confidence Score: 5/5Safe to merge — the change is a minimal, targeted guard that mirrors an identical pattern already present in the same function. The fix is a one-line conditional splice inside a single query-builder function. It follows the exact same pattern as the requestChannelFields guard directly above it, and no new logic paths are introduced. Users with canViewChannels = true continue to receive channel data; users without the permission simply omit that field — no data loss or regression risk. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant UI as Frontend
participant GQL as GraphQL API
participant Auth as Permission Guard
Note over UI: User has read_requests only (no read_channels)
UI->>GQL: GetRequests query
GQL->>Auth: Check read_requests → ✅ Allowed
alt BEFORE fix: channel always requested inside executions
GQL->>Auth: Check read_channels (RequestExecution.channel) → ❌ Denied
GQL-->>UI: Permission error – page fails entirely
end
alt AFTER fix: channel inside executions guarded by canViewChannels
Note over UI: canViewChannels = false → executionChannelFields = ""
GQL-->>UI: Returns modelID + status (no channel) → ✅ Page loads
end
Reviews (1): Last reviewed commit: "fix(frontend): guard execution channel q..." | Re-trigger Greptile |
Avoid requesting request execution channel fields when users only have request log access. Co-authored-by: Cursor <cursoragent@cursor.com>
Bug 现象
当用户只有
read_requests权限、没有read_channels权限时,访问/project/requests请求日志页面会失败并提示无权限。预期行为是:该用户可以查看请求日志列表,但不显示渠道相关信息。问题原因
GetRequests前端 GraphQL 查询中,顶层request.channel已根据canViewChannels做了条件拼接,但executions子查询里的channel { id name }仍然是无条件请求。后端
Channel查询策略要求read_channels权限,因此只有read_requests的用户虽然可以查询Request,但 GraphQL 展开RequestExecution.channel时会触发Channel权限校验并被拒绝。修复方法
将请求列表查询中的
executions.channel改为按canViewChannels条件拼接:read_channels权限时,继续请求并展示渠道信息。read_channels权限时,不再请求channel字段,只保留modelID、status等非渠道字段。这样可以保持后端权限模型不变,同时允许只有
read_requests权限的用户正常查看请求日志。