# 模块 1：RBAC 权限模型设计

<div class="mt-6 text-sm">

工单模块不是普通 CRUD。复杂度不在字段多少，而在谁能看、谁能改、什么条件下能改，以及出问题后能否追溯。

</div>

<div class="grid grid-cols-5 gap-3 mt-8 text-sm">
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">管理员</div>
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">负责人</div>
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">研发</div>
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30 text-center">测试</div>
<div class="p-3 rounded-xl bg-gray-500/10 border border-gray-500/30 text-center">只读用户</div>
</div>

<!--
第四天从权限矩阵开始，不是因为权限最容易写，而是因为权限最容易被 AI 简化成 CRUD 默认逻辑。
工单模块看起来只是增删改查，但真实企业系统里，不同角色看到的数据、能执行的动作、承担的责任完全不同。
如果不先设计矩阵，AI 很容易把新增、编辑、删除、指派、关闭这些按钮都生成出来，后面再补权限就会很被动。
-->

---

# 先矩阵，后代码

<div class="grid grid-cols-2 gap-6 mt-7 text-sm">
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
<div class="font-bold mb-2">错误顺序</div>

1. 先生成页面和接口
2. 再临时隐藏按钮
3. 最后补权限说明
</div>
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
<div class="font-bold mb-2">推荐顺序</div>

1. 先定义角色和动作
2. 再生成权限矩阵
3. 最后落到菜单、按钮、接口、数据范围
</div>
</div>

<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
权限矩阵是后续代码生成、Review 和验收的依据，不是交付后的补充说明。
</div>

<!--
这里要强调开发顺序。
AI 辅助开发最常见的问题，是先让它把 CRUD 做出来，再问“怎么加权限”。
这样会导致权限变成页面装饰，而不是业务规则。
正确做法是先用矩阵约束代码生成：哪些角色能看、能改、能流转、能删除、能看审计。
后面所有页面按钮、后端接口、数据范围和测试账号，都要回到这张矩阵。
-->

---

# RBAC 权限矩阵

<div class="mt-3 text-[11px] leading-tight">

| 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
|---|---|---|---|---|---|
| 查看列表 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
| 查看详情 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
| 新增工单 | Y | Y | Y | Y | N |
| 编辑工单 | Y | 条件允许 | 条件允许 | 条件允许 | N |
| 删除工单 | Y | N | N | N | N |
| 指派工单 | Y | 条件允许 | N | N | N |
| 提交验证 | Y | 条件允许 | Y | N | N |
| 关闭工单 | Y | 条件允许 | N | Y | N |
| 查看审计 | Y | 条件允许 | 条件允许 | 条件允许 | N |
| 查看看板 | Y | Y | 条件允许 | 条件允许 | 条件允许 |

</div>

<!--
这张矩阵是课堂产出，不是讲师单方面给答案。
AI 可以生成初稿，但最终必须由业务和团队确认。
“条件允许”不能只写四个字，必须落到条件：只能看自己创建的工单、只能处理指派给自己的工单、只能关闭待验证状态的工单，还是只能查看所在团队的数据。
如果条件写不清，后端数据权限和测试用例就没法落地。
-->

---

# 条件允许要展开

<div class="mt-5 text-sm">

| 条件类型 | 示例 | 验收方式 |
|---|---|---|
| 数据范围 | 只能看本人、本人团队、本人负责的工单 | 不同账号列表数量不同 |
| 状态限制 | 只有待验证才能关闭 | 非目标状态接口返回拒绝 |
| 角色叠加 | 负责人兼管理员时按更高权限 | 用双角色账号验证 |
| 字段限制 | 研发只能改处理说明，不能改优先级 | 提交非法字段被拒绝 |
| 时间限制 | 已关闭工单超过窗口不能重开 | 超时重开失败 |

</div>

<!--
这是原来矩阵里容易被忽略的知识点。
RBAC 不是只有允许和拒绝，真实业务里大量规则都是条件允许。
条件允许一旦不展开，AI 生成代码时就会把它理解成允许，测试时也不知道怎么验证。
所以矩阵之后必须补条件表，让权限从“角色判断”扩展到“角色 + 数据 + 状态 + 字段 + 时间”的组合判断。
-->

---

# 权限矩阵 Prompt

<div class="mt-5 text-sm">

```md
请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。

角色：
管理员、负责人、研发、测试、只读用户。

功能点：
查看列表、查看详情、新增、编辑、删除、指派、
提交验证、关闭、驳回、查看审计记录、查看看板。

要求：
1. 区分允许、拒绝、条件允许。
2. 条件允许必须展开为数据、状态、字段或时间条件。
3. 每个敏感操作给出后端接口验收方式。
4. 标注哪些权限属于业务待确认。
5. 不要直接生成代码。
```

</div>

<!--
这里训练学员不要直接让 AI 改代码。
先生成矩阵，再确认业务边界，最后才进入权限控制方案。
Prompt 里一定要写“不要直接生成代码”，因为这一页的目标是规则设计，不是实现。
另外要让 AI 标注待确认项：谁能删除、谁能导出、谁能查看审计日志，这些不能让 AI 自己拍板。
-->

---

# AI 容易漏掉的权限风险

<div class="mt-5 text-sm">

| 风险 | 表现 | Review 问法 |
|---|---|---|
| 前端按钮替代权限 | 按钮隐藏，但接口可直接调 | 无权限账号直接请求会怎样 |
| 数据范围缺失 | 所有人看到同一批工单 | 普通用户能否看到他人数据 |
| 条件允许泛化 | “条件允许”被实现成允许 | 条件在哪里校验 |
| 审计权限遗漏 | 审计日志对不该看的人开放 | 谁能看 old/new value |
| 删除权限过宽 | 负责人或研发能删除工单 | 删除是否只限管理员 |

</div>

<!--
这一页是给后续 Review 铺垫。
AI 很容易把权限理解成“有没有按钮”，但企业系统真正的风险在接口和数据范围。
课堂里可以让学员拿这张表去追问 TRAE：这个权限风险在哪个文件、哪个接口、哪个测试账号可以验证。
这样权限矩阵就不是一张漂亮表，而是 Review 和验收的入口。
-->

---

# 可直接复制到 rules：权限安全

<div class="mt-5 text-xs">

```md
## 敏感操作必须四层校验
- 级别：硬约束
- 适用场景：新增、编辑、删除、指派、状态流转、查看审计、查看看板。
- 必须：同时覆盖页面/菜单权限、按钮权限、后端接口权限、数据范围权限。
- 禁止：只做页面或按钮控制。
- 验收方式：授权角色能完成；未授权角色前端不可见且直接请求接口失败；越权数据访问失败。

## 权限字符必须有来源或标记为建议
- 必须：来自现有菜单、权限配置、前端权限指令、后端鉴权注解或团队规范。
- 禁止：凭空编造权限字符并当成事实。
- 验收方式：权限字符在前端、菜单配置、后端接口之间一致。

## 数据权限不得被查询条件替代
- 必须：后端统一校验当前用户可访问的数据范围。
- 禁止：只依赖前端传入 userId、deptId、tenantId 或筛选条件。
```

</div>

<!--
这页把交付包里的 security-permission 规则压缩成课堂可直接使用的版本。
重点不是让学员背规则，而是让他们知道第四天的权限实操必须写进 rules，并且每条 rules 都要有适用场景、必须、禁止和验收方式。
后续权限矩阵、权限控制方案和阶段 Review 都要回到这几条规则。
-->