Linker 使用基于角色的权限控制模型（RBAC）管理系统访问范围。
用户可以拥有多个角色，而角色决定了用户对各个实体的可操作范围。

权限控制不仅区分“是否允许新增”，还会精确控制记录级范围。权限判断与记录中的 所属人、所属部门 字段密切相关。

角色 ​

角色是权限分配的载体。
常见做法是按岗位或职责拆分角色，例如：

  • 销售
  • 销售主管
  • 财务
  • 项目经理
  • 系统管理员

一个用户可以配置多个角色，系统会综合这些角色的权限结果。

权限项 ​

当前系统的实体权限主要包括：

  • 添加
  • 删除
  • 编辑
  • 查询
  • 分配
  • 共享

其中：

  • 添加 是开关权限，开启后才允许新建
  • 其他权限通常是范围权限，除了能不能做，还要判断能对哪些记录做

权限范围 ​

根据当前实现，权限范围支持以下几种深度：

  • 本人
  • 本部门
  • 本部门及下级部门
  • 过滤条件
  • 全部

本人 ​

只能操作 所属人 = 当前用户 的记录。

本部门 ​

只能操作 所属部门 = 当前用户所在部门 的记录。

本部门及下级部门 ​

除了本部门外，还包含当前部门下所有子部门的记录。

过滤条件 ​

通过自定义条件决定权限范围。
适合更复杂的业务限制，例如：

  • 仅查看某类客户
  • 仅编辑特定状态的记录

全部 ​

可操作该实体的全部记录。

权限范围最终依赖记录中的 所属人、所属部门 字段来判断，因此这些基础字段的维护非常重要。

权限是如何生效的 ​

在当前系统实现中：

  • 查询列表时，会按角色生成数据过滤条件
  • 编辑、删除、分配等操作时，也会再次校验当前记录是否落在权限范围内

这意味着即使用户知道某条记录的 ID，如果该记录不在其权限范围内，也不能绕过权限直接操作。

角色设计建议 ​

  • 按岗位职责建角色，不要按个人建角色
  • 优先通过范围控制权限，而不是给所有人“全部”
  • 普通业务岗优先使用“本人”或“本部门”
  • 管理岗根据职责扩展到“本部门及下级部门”或“全部”
  • 复杂规则再使用“过滤条件”

与分配操作的关系 ​

由于权限依赖 所属人 和 所属部门，所以记录分配不仅是业务交接，也会影响谁能看到、谁能操作这条记录。
当人员离职、调岗或客户交接时，应及时使用 基础操作中的分配 调整归属关系。

常见理解误区 ​

  • 角色不是菜单分组，它本质上控制的是操作能力和数据范围
  • “能看到实体入口” 不等于 “能看到该实体全部数据”
  • 给了编辑权限，也不代表能编辑所有记录，还要看范围
  • 多个角色同时存在时，通常会叠加出更大的可用范围

Linker