smart
162 lines
6.3 KiB
Markdown
162 lines
6.3 KiB
Markdown
# 模块 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-5 text-xs">
|
||
|
||
| 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
|
||
|---|---|---|---|---|---|
|
||
| 查看列表 | 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 和验收的入口。
|
||
-->
|