跳到主要内容

权限设计与权限矩阵

1. 文档定位​

本文档描述数据分析 AI Agent 平台已经实现并实际生效的权限体系，结论以以下代码为准：

  • server/app/services/access/permission_service.py
  • server/app/api/deps.py
  • server/app/core/security/permissions.py
  • server/app/core/runtime/request_context.py
  • server/app/api/v1/*.py
  • server/app/modules/agent/api.py
  • server/app/modules/agent/tools.py
  • server/mcp_server/server.py
  • server/mcp_server/auth.py
  • web/src/stores/user.ts
  • web/src/router/index.ts
  • web/src/components/layout/AppSidebar.vue
  • web/src/views/PermissionView.vue

2. 当前权限体系总览​

本平台的权限体系分为 4 层：

  1. 系统角色层

    • sys_user_permission.role_type 决定用户基础角色。
    • 默认角色矩阵来自 ROLE_PERMISSION_FLAGS，可被角色模块权限表覆盖。

  2. 功能权限层

    • 后端以 permission_flags 作为主判断依据。
    • 每个权限键的值为 allow、partial、deny。
    • 绝大多数业务 API、前端路由可见性、MCP 工具访问都依赖这一层。

  3. 协作组层

    • 协作组是类似聊天群的人员容器，普通用户或负责人可创建和管理自己拥有的协作组。
    • 协作组用于共享空间邀请、成员协作和资源编辑，不参与 permission_flags 合并。

  4. 资源授权层

    • 共享空间通过 project_space_principals 绑定 user、group、collaboration_group 主体。
    • 资源级 ACL 继续由 sys_resource_acl 承载，用于脱离共享空间的长期资源授权。

权限管理后台层由超级管理员使用：

  • 超级管理员可管理角色、用户、权限组、字段权限、角色模块矩阵。
  • 这些能力主要由 /v1/permission/* 提供。
  • /v1/permission/user-groups 名称保持兼容，但当前语义为"权限组"，不会返回协作组。

3. 主权限模型​

3.1 权限数据来源​

当前登录用户的有效主权限来自：

  • sys_user_permission.role_type
  • ROLE_PERMISSION_FLAGS
  • sys_role_module_permission（覆盖表）
  • sys_group_module_permission（权限组模块权限，已合并到个人 permission_flags）

后端 /v1/auth/me 返回：

  • roles
  • permissions
  • permission_flags

其中真正用于接口鉴权和前端显隐控制的是 permission_flags。

3.2 权限级别语义​

级别含义
allow完整允许
partial部分允许，是否可通过取决于接口是否允许 partial
deny拒绝

3.3 partial 的生效规则​

本平台不是所有接口都接受 partial：

  • 接受 partial

    • dashboard_view
    • query_view
    • query_export
    • 部分 MCP/JWT 校验链路把 partial 视为可通过

  • 仅接受 allow

    • alert_view
    • alert_config
    • dashboard_custom_view
    • report_view
    • segment_view
    • project_space_view
    • ai_chat
    • 绝大多数管理类权限

注意：上述"仅接受 allow"的权限中，前端 stores/user.ts 实际上对 dashboard_custom_view、report_view、segment_view、project_space_view 都接受 partial，但后端业务 API 使用的 require_permission 默认 allow_partial=False，这会导致拥有 partial 权限的用户前端能看到页面但调用后端 API 时收到 403。详见第 13 节。

4. 角色体系​

当前系统固定 5 个角色：

角色 IDrole_type用途
role_super_adminsuper_admin平台级管理员，拥有全部主权限
role_project_adminproject_admin项目管理员，拥有大部分业务权限，但不能管理权限体系本身
role_operatoroperator运营角色，可看大部分业务数据，部分导出/删除能力受限
role_developerdeveloper研发角色，可访问技术/分析相关能力，但不能访问自定义看板、报表、分群、共享空间
role_no_permissionno_permission无权限用户，登录后仅能看到联系管理员提示页，需被授权后才能使用功能

4.1 全局角色与项目级别的区分​

  • role_type 是全局能力身份：决定用户能使用哪些平台功能，以及是否具备项目管理员的能力。
  • project_ids[].level 是项目级权限范围：决定用户在某个项目中的实际权限，取值 read / write / admin。
  • project_admin 是能力角色：持有该 role_type 的用户可以管理其 project_ids 中所有 level=admin 的项目。
  • 项目成员管理接口只修改 project_ids[].level；当 level=admin 且用户原本不是 super_admin/project_admin 时，自动将其 role_type 提升为 project_admin。

5. 主权限键清单​

5.1 通用业务权限​

权限键含义
dashboard_view查看内置业务看板 Tab
dashboard_custom_view查看和管理自定义看板
dashboard_export看板导出
query_view明细查询
query_export明细导出
ai_chatChat Agent 对话
alert_view查看告警
alert_config管理告警、渠道、静默规则
report_view自定义报表
segment_view用户分群
project_space_view共享空间
permission_manage权限管理后台能力
project_member_manage项目成员与项目组管理（项目维度）

5.2 Event Analysis 权限​

权限键含义
event_analysis_view查看事件分析配置和元数据
event_analysis_create创建事件分析
event_analysis_update更新事件分析
event_analysis_delete删除事件分析
event_analysis_execute执行事件分析

5.3 MCP 权限​

权限键含义
mcpMCP 总开关
mcp_get_current_timeMCP 时间工具
mcp_calculatorMCP 计算器工具

6. 默认角色权限矩阵​

以下矩阵来自 ROLE_PERMISSION_FLAGS 的当前默认值。

6.1 主业务矩阵​

权限键超级管理员项目管理员运营研发
dashboard_viewallowallowallowpartial
dashboard_custom_viewallowallowallowdeny
dashboard_exportallowallowpartialdeny
query_viewallowallowpartialpartial
query_exportallowallowdenydeny
ai_chatallowallowallowallow
alert_viewallowallowallowallow
alert_configallowallowdenydeny
report_viewallowallowallowdeny
segment_viewallowallowallowdeny
project_space_viewallowallowallowdeny
project_space_createallowallowdenydeny
project_space_updateallowallowdenydeny
project_space_deleteallowallowdenydeny
permission_manageallowdenydenydeny

6.2 Event Analysis 矩阵​

权限键超级管理员项目管理员运营研发
event_analysis_viewallowallowallowallow
event_analysis_createallowallowallowdeny
event_analysis_updateallowallowallowdeny
event_analysis_deleteallowallowpartialdeny
event_analysis_executeallowallowallowallow

6.3 Project Space 矩阵​

权限键超级管理员项目管理员运营研发
project_space_viewallowallowallowdeny
project_space_createallowallowdenydeny
project_space_updateallowallowdenydeny
project_space_deleteallowallowdenydeny

6.4 Project Members 矩阵​

权限键超级管理员项目管理员运营研发
project_member_manageallowallowdenydeny

说明：project_member_manage 控制 /api/v1/projects/{project_id}/members 与 /api/v1/projects/{project_id}/groups 接口族。project_admin 只能管理其 project_ids 中 level=admin 的项目。

6.5 MCP 矩阵​

权限键超级管理员项目管理员运营研发
mcpallowallowallowallow
mcp_get_current_timeallowallowallowallow
mcp_calculatorallowallowallowallow

7. permission 与 permission_manage 的命名差异​

本平台存在一处需要特别说明的命名差异：

  • 后端主鉴权使用 permission_manage
  • /api/v1/config/permissions 和部分前端权限矩阵页面使用 permission

当前转换关系如下：

  1. 默认主权限内部存储为 permission_manage
  2. 角色矩阵配置接口对前端输出时改名为 permission
  3. 当角色矩阵写回覆盖表 sys_role_module_permission 时，如果模块 key 为 permission，后端会转回 permission_manage

因此：

  • 代码实现上应把 permission_manage 视为真实后端权限键
  • 配置 API / 权限页面展示层把 permission 视为该权限的前端展示名

8. API 与路由权限落点​

8.1 内置看板与筛选相关​

模块接口文件权限
业务看板 Tabapp/api/v1/dashboard/__init__.pydashboard_view
看板阈值更新app/api/v1/dashboard_meta.pyalert_config
看板导出app/api/v1/dashboard_meta.pydashboard_export
筛选模板app/api/v1/analysis/filter_templates.pydashboard_view (allow_partial=False)

8.2 查询与对比​

模块接口文件权限
明细查询app/api/v1/query_detail.pyquery_view
Cube 聚合查询app/api/v1/query_cube.pyquery_view
导出任务app/api/v1/query_export.pyquery_export
VS 对比app/api/v1/analysis/vs_comparison.pyquery_view

8.3 告警体系​

模块接口文件权限
告警查看app/api/v1/monitoring/alert.pyalert_view (仅 allow)
告警规则增删改测app/api/v1/monitoring/alert.pyalert_config (仅 allow)
通知渠道增删改测app/api/v1/monitoring/alert.pyalert_config (仅 allow)
静默规则增删改app/api/v1/monitoring/alert.pyalert_config (仅 allow)

8.4 自定义报表 / 看板​

模块接口文件权限
自定义报表 CRUDapp/api/v1/analysis/data_reports.pyreport_view (allow_partial=False)
自定义看板实例 CRUDapp/api/v1/dashboard_instances.pydashboard_custom_view (allow_partial=False)
看板组件增删改app/api/v1/dashboard_instances.pydashboard_custom_view (allow_partial=False)

注意：自定义报表和自定义看板都只有单一权限键，没有区分查看/创建/编辑/删除。

8.5 分群与共享空间​

模块接口文件权限
用户分群 CRUDapp/api/v1/analysis/user_segments.pysegment_view (allow_partial=False)
共享空间列表/详情app/api/v1/collaboration/project_spaces.pyproject_space_view
共享空间创建app/api/v1/collaboration/project_spaces.pyproject_space_create (allow_partial=False)
共享空间编辑app/api/v1/collaboration/project_spaces.pyproject_space_update (allow_partial=False)
共享空间删除app/api/v1/collaboration/project_spaces.pyproject_space_delete (allow_partial=False)
共享空间成员管理app/api/v1/collaboration/project_spaces.pyproject_space_update (allow_partial=False)，空间创建者/成员/超管可操作
共享空间资源管理app/api/v1/collaboration/project_spaces.pyproject_space_update (allow_partial=False)，空间创建者/成员/超管可操作

注意：共享空间已按 Event Analysis 模式拆分为 view/create/update/delete 四级权限。空间名称编辑、删除仍由 Service 层保留 owner/超管校验；成员管理与资源管理允许已加入该共享空间的协作者操作。共享空间中的报表/看板资源对空间成员提升为协作编辑权限，但不改变资源 created_by。

8.6 Project Members​

模块接口文件权限
项目成员管理app/modules/project/members.pyproject_member_manage (allow_partial=False)
项目组管理app/modules/project/members.pyproject_member_manage (allow_partial=False)

说明：项目成员接口修改的是 sys_user_permission.project_ids 中对应项目的 level，不会跨项目影响用户在其他项目的权限；level=admin 会自动将用户 role_type 提升为 project_admin。

8.7 Event Analysis​

操作接口文件权限
列表、详情、元数据app/api/v1/analysis/event_analysis.pyevent_analysis_view
创建、另存为app/api/v1/analysis/event_analysis.pyevent_analysis_create
执行app/api/v1/analysis/event_analysis.pyevent_analysis_execute
更新app/api/v1/analysis/event_analysis.pyevent_analysis_update
删除app/api/v1/analysis/event_analysis.pyevent_analysis_delete

8.8 Agent API​

接口文件权限声明
/agent/chatapp/modules/agent/api.pyai_chat
/agent/chat/streamapp/modules/agent/api.pyai_chat
/agent/queryapp/modules/agent/api.pyquery_view (allow_partial=True)
/agent/analyzeapp/modules/agent/api.pydashboard_view (allow_partial=True)
/agent/report/generateapp/modules/agent/api.pyai_chat
/agent/watcher/statusapp/modules/agent/api.pyalert_config
/agent/sessions/{id}/context (GET/DELETE)app/modules/agent/api.pyrequire_session_owner
/agent/admin/config/reloadapp/modules/agent/api.pyrequire_super_admin

8.9 权限管理后台​

/v1/permission/* 整组接口由 require_super_admin 保护，仅超级管理员可访问。

9. 前端权限控制​

前端权限控制主要基于 /v1/auth/me 返回的 permission_flags，核心位置：

  • web/src/stores/user.ts
  • web/src/router/index.ts
  • web/src/components/layout/AppSidebar.vue
  • web/src/views/PermissionView.vue

9.1 前端已使用的主要判断​

前端状态来源权限接受 partial
canViewDashboarddashboard_view是
canViewCustomDashboarddashboard_custom_view是
canQueryViewquery_view是
canQueryExportquery_export是
canDashboardExportdashboard_export是
canAiChatai_chat否（仅 allow）
canAlertViewalert_view否（仅 allow）
canAlertConfigalert_config否（仅 allow）
canViewReportreport_view是
canViewSegmentsegment_view是
canViewProjectSpaceproject_space_view是
canManageProjectMembersproject_member_manage否（仅 allow）
isSuperAdminroleIds 包含 role_super_admin-

9.2 默认首屏跳转顺序​

用户登录后，前端会按如下顺序选择第一个有权限的页面：

  1. /dashboard
  2. /dashboards
  3. /data-reports
  4. /user-segments
  5. /project-spaces
  6. /query
  7. /report
  8. /config
  9. /permission

9.3 路由守卫权限检查​

router/index.ts 中对以下路由做了权限拦截：

  • /admin、/permission -> isSuperAdmin
  • /dashboard -> canViewDashboard
  • /dashboards/* -> canViewCustomDashboard
  • /data-reports/* -> canViewReport
  • /user-segments/* -> canViewSegment
  • /project-spaces -> canViewProjectSpace
  • /query -> canQueryView
  • /report -> canAlertView
  • /config -> canAlertConfig

缺失：/chat 和 /event-analysis 未在路由守卫中做权限检查。

10. 权限管理后台能力​

10.1 角色矩阵​

当前已支持：

  • 查看 4 个内置角色
  • 查看角色人数
  • 查看角色-模块矩阵
  • 更新非超级管理员角色的矩阵单元格

相关接口：

  • GET /v1/permission/roles
  • GET /v1/permission/role-module-matrix
  • PUT /v1/permission/role-module-matrix

10.2 用户管理​

当前已支持：

  • 创建用户
  • 修改角色
  • 修改密码
  • 修改邮箱
  • 启用 / 禁用
  • 删除用户
  • 批量改角色
  • 批量启用 / 禁用

相关数据表以 sys_user、sys_user_permission 为主。

10.3 权限组与协作组​

当前 sys_user_group 同时承载两类组：

组语义group_kind管理入口是否合并 permission_flags用途
权限组permission（旧数据默认值）/api/v1/permission/user-groups是后台权限授权与权限矩阵增强
协作组collaboration/api/v1/collaboration-groups否共享空间协作、成员容器、资源协同编辑

权限组当前已支持：

  • 权限组 CRUD
  • 权限组成员维护
  • 配置 module_permissions（按模块的 allow/partial/deny）

重要修正：只有权限组模块权限会并入主鉴权链路。在 permission_service.py 中：

  • get_user_me() 会调用 _get_group_permission_flags() 并将结果与角色权限合并
  • list_users() 也会为每个用户计算合并后的 permission_flags
  • 合并规则是"取高权限"（deny < partial < allow）
  • _get_group_module_permissions_map() 只读取最新有效 group_kind='permission' 的组，空值按旧权限组兼容

因此，权限组附加权限会参与后端业务接口鉴权和前端 permission_flags 展示；协作组即使历史上存在模块权限记录，也不会提升系统权限。

协作组当前已支持：

  • 普通用户创建自己拥有的协作组
  • owner/manager 添加或移除成员
  • 被共享空间以 principal_type='collaboration_group' 邀请
  • 协作组成员访问共享空间，并编辑空间内共享报表/看板

协作组入口收敛：

  • 协作组不再有独立菜单页面，普通用户仅在共享空间"添加协作组"流程内创建/选择协作组。
  • 协作组不是权限主体，不参与 permission_flags 合并；权限组仅由超级管理员在 /permission 后台维护，不在共享空间新增流程中暴露入口。
  • 共享空间内，协作组主体支持"查看成员"入口；成员增删的最终鉴权由后端 CollaborationGroupService 完成（非 owner/manager 返回 403）。

11. 字段权限现状​

字段权限当前是一个独立的补充能力，不是平台主权限模型。

11.1 当前支持内容​

字段权限接口：

  • GET /v1/permission/field-permissions
  • PUT /v1/permission/field-permissions

字段权限值：

  • allow
  • mask
  • aggregate_only
  • deny

当前默认静态规则主要覆盖：

  • 登录明细表 login
  • 订单明细表 order

并可被 sys_field_permission 覆盖。

11.2 当前实现边界​

当前代码层面，字段权限主要体现为：

  • 权限管理后台可查看和修改配置
  • 服务层能返回登录/订单字段矩阵

但它不是当前业务 API 的统一主鉴权基础，不能再按旧文档理解为"所有数据接口都先做字段脱敏再返回"。

12. Agent 与 MCP 权限设计​

12.1 Chat Agent​

Agent API 的权限入口如下：

  • 聊天：ai_chat
  • 直接查询：query_view
  • 归因分析：dashboard_view
  • 报告生成：ai_chat
  • Watcher 状态：alert_config

Agent 工具权限映射定义在：

  • server/app/core/security/permissions.py（TOOL_PERMISSION_MAP）
  • server/app/modules/agent/tools.py（MCP_TOOL_PERMISSIONS）

主要工具类型包括：

  • 数据查询
  • 指标分析
  • 图表生成
  • 内置业务看板读取
  • 报告预览
  • 报告订阅管理
  • 告警 / 通知渠道 / 静默规则管理
  • AI 端点配置管理

12.2 MCP​

MCP 有两层权限控制：

  1. 连接侧权限

    • JWT
    • API Key（以 ga_ 开头）
    • Static token（环境变量 MCP_AUTH_TOKEN）
    • 匿名（MCP_ALLOW_ANONYMOUS=true 时）

  2. 工具侧权限

    • 总开关：mcp
    • 内置细粒度键：如 mcp_get_current_time、mcp_calculator
    • 工具权限映射定义在 app/modules/agent/tools.py

当前 MCP 暴露的工具能力包括：

  • 查询与分析
  • 看板读取
  • 报告预览
  • 报告订阅管理
  • 告警规则管理
  • 通知渠道管理
  • 静默规则管理
  • AI 端点管理

12.3 MCP 权限检查的双实现问题​

当前存在两套 MCP 权限检查代码，逻辑不完全一致：

文件用途特点
mcp_server/auth.pySSE 连接层通用检查匿名用户仅允许 query_view/dashboard_view；静态 Token 额外允许 alert_view/mcp*；JWT/API Key 用户查询 permission_flags，allow/partial 均通过
app/modules/agent/tools.pyAgent/MCP 工具调用检查存在 BUILTIN_MCP_TOOLS 白名单（默认允许）；未配置权限的非内置工具默认拒绝；通过 MCP_TOOL_PERMISSIONS 映射到具体权限键

两套检查应统一或明确分工，避免权限判断结果不一致。

13. 当前权限设计的冲突与不足​

13.1 Event Analysis 前后端权限不一致（高优先级）​

问题描述：

  • 前端 AppSidebar.vue 中，event-analysis 菜单的显隐条件是 userStore.canViewDashboard（基于 dashboard_view）
  • 后端 event_analysis.py 所有接口依赖的是独立的 event_analysis_view/create/update/delete/execute 权限

导致的后果：

  1. 拥有 dashboard_view 但无 event_analysis_view 的用户：前端能看到"事件分析"菜单，但点击后后端 API 返回 403
  2. 拥有 event_analysis_view 但无 dashboard_view 的用户：前端看不到"事件分析"菜单，但直接调用后端 API 可以正常访问

建议：前端菜单显隐应改为基于 event_analysis_view，与后端保持一致。

13.2 Chat 路由缺少前端权限守卫（高优先级）​

问题描述：

  • 前端路由守卫 router/index.ts 未对 /chat 路径做任何权限检查
  • 后端 /agent/chat 和 /agent/chat/stream 需要 ai_chat 权限

导致的后果：

无 ai_chat 权限的用户可以通过直接输入 URL 进入聊天页面，虽然后端会拒绝发送消息，但用户体验差且前端没有提前拦截。

建议：在路由守卫中为 chat / chat-session 添加 canAiChat 检查。

13.3 require_permission 默认参数不一致导致 partial 权限失效（严重）​

问题描述：

平台中有两个同名的 require_permission 实现，默认参数不同：

来源文件默认 allow_partial是否有缓存
app/core/runtime/request_context.pyFalse否
app/core/security/permissions.pyTrue是（60s）

业务 API 中大量使用了 app.api.deps 导出的版本（即 request_context.py 版），且未显式指定 allow_partial。

导致的后果：

以下 API 实际上仅接受 allow，不接受 partial，但前端对它们都接受 partial：

模块权限键前端是否接受 partial后端是否接受 partial
自定义看板dashboard_custom_view是否
自定义报表report_view是否
用户分群segment_view是否
共享空间project_space_view是否
筛选模板dashboard_view是否

这意味着：如果某角色（如 developer）对这些权限是 partial，前端会显示对应菜单，但用户访问页面时后端会返回 403。

建议：

  • 方案 A：统一所有业务 API 使用 app.core.permissions 中的 require_permission（默认 allow_partial=True），对确实需要严格 allow 的接口显式传 allow_partial=False
  • 方案 B：修改前端 stores/user.ts，将 canViewCustomDashboard、canViewReport、canViewSegment、canViewProjectSpace 改为仅接受 allow

从业务语义上，方案 A 更合理（partial 应该表示"受限访问"，而不是"完全拒绝"）。

13.4 自定义看板 / 报表 / 分群 / 共享空间的权限粒度过粗（设计缺陷）​

问题描述：

以下模块都只有一个权限键，没有区分 CRUD：

  • dashboard_custom_view：查看、创建、编辑、删除看板及组件
  • report_view：查看、创建、编辑、删除报表
  • segment_view：查看、创建、编辑、删除分群
  • project_space_view：查看、创建、编辑、删除共享空间，以及成员管理、资源管理（已修复：已拆分为 project_space_view/create/update/delete）

导致的后果：

只要用户拥有上述任一权限的 allow，就可以执行该模块的所有操作（包括删除他人的数据）。虽然部分模块在 Service 层做了"仅创建者可删除"的硬编码，但这不属于权限体系的控制。

建议：

  • 短期：在文档和代码中明确当前粒度，保持统一
  • 中期：考虑将 dashboard_custom_view / report_view / segment_view 拆分为 *_view / *_create / *_update / *_delete 等更细粒度的权限键（类似 Event Analysis 和 Project Space 的设计）

13.5 共享空间权限控制混合了两套机制（设计不一致）—— 已修复​

问题描述（修复前）：

  • API 层：共享空间所有操作统一检查 project_space_view
  • Service 层：更新、删除、成员管理、资源管理等操作硬编码为"仅创建者可执行"（PermissionError）

修复内容：

  • API 层已按操作类型拆分：project_space_view（读）、project_space_create（创建）、project_space_update（编辑/成员/资源）、project_space_delete（删除），写操作均使用 allow_partial=False
  • Service 层 _ensure_owner 已增加超管放行：permission_checker.is_super_admin(user_id) 为真时跳过 owner 检查
  • MODULE_KEYS 和前端 MATRIX_ROWS 已同步新增上述三个权限键

剩余边界：

非超管用户即使拥有 project_space_update 权限，仍然需要是空间 owner 才能修改空间名称或删除空间（保留空间级破坏性操作的数据范围控制）。成员管理和资源管理已开放给共享空间协作者；共享空间中的报表/看板写操作也允许空间协作者执行。资源表中的 created_by 不随共享空间协作而变更；需要脱离共享空间的长期授权时，仍应使用 sys_resource_acl。

13.6 MODULE_KEYS 和前端权限矩阵缺失 Event Analysis / MCP 权限 —— 已修复​

修复内容：

  • MODULE_KEYS 已补齐 event_analysis_*、mcp*、project_space_member_manage、project_space_resource_manage
  • PermissionView.vue 的 MATRIX_ROWS 已同步展示上述权限键
  • stores/user.ts 已补充对应派生状态

13.7 部分 require_permission 调用来源混乱 —— 已修复​

app/api/deps.py 当前统一从 app.core.permissions re-export require_permission。app.core.request_context 保留 get_current_user、get_request_id 等上下文依赖；旧同名权限依赖不再作为 API 层统一出口。

13.8 Agent 会话所有权校验的潜在问题​

问题描述：

require_session_owner 在 app/modules/agent/deps.py 中实现，它通过 AgentSessionStorage.load(session_id) 判断会话所有者。

潜在问题：

  • 如果会话存储失败或延迟，可能误判所有权
  • 超级管理员可以 bypass，但其他具有管理角色的用户无法查看下属会话

建议：当前实现基本可用，但如需支持管理员查看团队会话，应引入角色 bypass 或团队/项目维度校验。

14. 改进建议汇总​

优先级问题建议方案状态
P0Event Analysis 前后端权限不一致前端菜单显隐改为 event_analysis_view；路由守卫补充 /event-analysis 检查已修复：前端 canViewEventAnalysis 检查 event_analysis_view；后端 event_analysis.py 使用 PERM_EVENT_ANALYSIS_VIEW
P0Chat 路由缺少权限守卫路由守卫补充 /chat / chat-session 的 canAiChat 检查已修复：router/index.ts 已补充 chat / chat-session 的 canAiChat 守卫
P0require_permission 默认参数不一致统一使用 app.core.permissions.require_permission；需要严格 allow 的接口显式传 allow_partial=False部分修复：写操作接口（create/update/delete/execute）已显式传 allow_partial=False；alert_view 使用 require_alert_view 强制 allow_partial=False；读操作接口（view）保持默认 allow_partial=True 以兼容 partial 语义
P1权限粒度过粗project_space_view 已拆分；中期继续拆分 dashboard_custom_view / report_view / segment_view 为 CRUD 权限
P1共享空间权限硬编码已修复：引入 project_space_create/update/delete，API 层统一控制，Service 层超管放行
P1MODULE_KEYS 缺失已修复：补充 event_analysis_*、mcp*、共享空间细粒度权限到 MODULE_KEYS 和前端 MATRIX_ROWS
P2MCP 权限检查双实现统一为一套逻辑，或明确 mcp_server/auth.py 负责连接层、app/modules/agent/tools.py 负责工具层，并文档化分工
P2权限检查来源混乱已修复主出口：app/api/deps.py 统一指向 app.core.permissions

15. 当前实现结论​

15.1 已经稳定生效的主体系​

  • 4 角色模型
  • permission_flags 主权限链路（含权限组权限合并，不含协作组）
  • 业务 API 权限控制
  • 前端页面可见性控制
  • Event Analysis 专项权限
  • Chat Agent / MCP 的读能力与部分管理能力

15.2 需要修复的不一致点​

  • Event Analysis 菜单与 API 权限不对应（已修复）
  • Chat 页面无路由守卫（已修复）
  • require_permission 默认 allow_partial=True，写操作接口已显式传 allow_partial=False，但默认值本身未改
  • MODULE_KEYS 和前端矩阵缺少 Event Analysis / MCP（已修复）

15.3 需要长期规划的设计改进​

  • 自定义看板、报表、分群的 CRUD 权限拆分（Project Space 已拆分完成）
  • MCP 权限检查逻辑统一

16. 相关代码索引​

模块文件
权限常量与工具映射server/app/core/security/permissions.py
请求上下文与鉴权依赖server/app/core/runtime/request_context.py
角色与权限矩阵server/app/services/permission_service.py
通用 API 权限依赖server/app/api/deps.py
权限管理接口server/app/api/v1/access/permission.py
配置接口server/app/api/v1/config.py
Agent APIserver/app/modules/agent/api.py
Agent 依赖/会话所有权server/app/modules/agent/deps.py
Agent 工具与 MCP 映射server/app/modules/agent/tools.py
MCP 认证server/mcp_server/auth.py
MCP 服务server/mcp_server/server.py
前端路由守卫web/src/router/index.ts
前端用户权限状态web/src/stores/user.ts
前端侧边栏显隐web/src/components/layout/AppSidebar.vue
前端权限管理页web/src/views/PermissionView.vue
聊天固定到看板web/src/components/chat/PinToDashboardModal.vue
加载评论中...