Skip to content

fix(frontend): guard execution channel query by permission#1770

Merged
looplj merged 1 commit into
looplj:unstablefrom
MoeMion:fix/request-permission-channel-query
Jun 3, 2026
Merged

fix(frontend): guard execution channel query by permission#1770
looplj merged 1 commit into
looplj:unstablefrom
MoeMion:fix/request-permission-channel-query

Conversation

@MoeMion

@MoeMion MoeMion commented Jun 3, 2026

Copy link
Copy Markdown

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 字段,只保留 modelIDstatus 等非渠道字段。

这样可以保持后端权限模型不变,同时允许只有 read_requests 权限的用户正常查看请求日志。

Avoid requesting request execution channel fields when users only have request log access.

Co-authored-by: Cursor <cursoragent@cursor.com>
Copilot AI review requested due to automatic review settings June 3, 2026 09:44

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 (channelFieldsrequestChannelFields).
  • 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.

Comment on lines +26 to +40
const requestChannelFields = permissions.canViewChannels
? `
channel {
id
name
}`
: '';

const executionChannelFields = permissions.canViewChannels
? `
channel {
id
name
}`
: '';
@greptile-apps

greptile-apps Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR fixes a permission error on the /project/requests page for users who have read_requests but not read_channels. The executions sub-query inside GetRequests was unconditionally fetching channel { id name }, which triggered the backend's read_channels permission check and rejected the whole request.

  • Renames the existing channelFields variable to requestChannelFields for clarity, since a second guard variable is now needed.
  • Adds executionChannelFields using the same permissions.canViewChannels conditional pattern, and splices it into status${executionChannelFields} within the executions.edges.node selection — matching the guard already present on the top-level request.channel.

Confidence Score: 5/5

Safe 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

Filename Overview
frontend/src/features/requests/data/requests.ts Renames channelFieldsrequestChannelFields and adds a new executionChannelFields guard in buildRequestsQuery, so executions.channel is only fetched when canViewChannels is true — matching the pre-existing guard already on request.channel.

Sequence Diagram

sequenceDiagram
    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
Loading

Reviews (1): Last reviewed commit: "fix(frontend): guard execution channel q..." | Re-trigger Greptile

@looplj looplj merged commit afaf90f into looplj:unstable Jun 3, 2026
4 checks passed
junjiangao pushed a commit to junjiangao/axonhub that referenced this pull request Jun 5, 2026
Avoid requesting request execution channel fields when users only have request log access.

Co-authored-by: Cursor <cursoragent@cursor.com>
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.

3 participants