配方权限的五种分类
权限分类这件事，说白了就是回答一个问题：这个人到底能对配方做什么？
我在做第一个配方系统时，犯过一个典型错误——把所有权限揉成一团，只分了「管理员」和「普通用户」。结果上线第一天，质检员不小心删掉了生产线的核心配方，整个车间停了两个小时。嗯，从那以后，我对权限分类再也不敢马虎了。
配方管理里，权限通常拆成五个维度。你想想看，这其实跟现实中的文档审批流程很像，只是更严谨一些。
2.1 查看权限（Read）
这是最基础的权限。说白了，就是「能不能看到这个配方」。
你可能会觉得，看到就看到呗，能有什么问题？我在项目里遇到过一件事：某工厂的配方成本明细里包含了供应商的独家报价，结果被一个实习生截图发到了行业群里……从那以后，我们就把查看权限又拆成了两级：
- 基础查看：只能看到配方名称、编号、版本号、状态等元信息
- 详细查看：能看到完整的物料清单、工艺参数、成本明细
我个人习惯的做法是：默认给「基础查看」，按需申请「详细查看」。这样既不影响日常协作，又能保护敏感数据。
2.2 编辑权限（Write）
编辑权限意味着用户可以修改配方内容。但这里有个坑——编辑不等于保存。
我曾经见过一个系统，编辑权限直接允许用户覆盖原配方。结果有人改完参数没测试，直接保存，导致后续批次全部报废。正确的做法是：
- 编辑权限只允许创建「草稿版本」或「修订版本」
- 修改后的配方必须进入审批流程
- 原配方在审批通过前保持只读状态
说白了，编辑权限应该理解为「提案权」，而不是「修改权」。你想想看，如果每个人都能直接改生产配方，那质量管控就形同虚设了。
2.3 审批权限（Approve）
审批权限是配方管理的核心关卡。它跟编辑权限是完全分离的——编辑的人不能审批，审批的人不能编辑。这是最基本的「职责分离」原则。
审批权限通常需要进一步细分：
| 审批层级 | 适用范围 | 典型角色 |
|---|---|---|
| 一级审批 | 常规参数调整、辅料替换 | 车间主任、工艺工程师 |
| 二级审批 | 主料变更、工艺路线调整 | 技术经理、质量总监 |
| 三级审批 | 核心配方变更、成本重大调整 | 研发总监、工厂厂长 |
我在实际项目中，还会给审批权限加一个「会签」功能。比如某个配方变更涉及多个部门，就需要质量、生产、采购三方都审批通过才行。这个机制虽然流程长一点，但能避免很多扯皮的事。
2.4 删除权限（Delete）
删除权限是最危险的权限之一。我个人的原则是：能不删就不删，能软删就别硬删。
什么叫软删？就是把配方标记为「已废弃」或「已归档」，但数据还在数据库里。硬删才是真正的物理删除。
我曾经在一个项目里吃过亏：客户要求「清理过期配方」，结果运维人员执行了物理删除。三个月后，审计发现某个批次的产品出了问题，需要追溯配方来源，但数据已经没了。那次事故直接导致我们重新设计了删除机制：
- 软删除：所有用户默认只有软删除权限
- 硬删除：只有系统管理员在特定窗口期（比如季度清理）才能执行
- 回收站：软删除的配方在回收站保留90天，期间可以恢复
2.5 管理权限（Admin）
管理权限是最高级别的权限。它包含但不限于：
- 创建/删除配方分类目录
- 配置权限模板和角色
- 查看所有操作日志
- 执行数据迁移和批量操作
- 管理用户账号和权限分配
管理权限应该给谁？我的建议是：给「流程管理者」，而不是「业务执行者」。比如质量体系管理员、IT系统管理员，而不是某个配方的实际使用者。
你想想看，如果生产主管同时拥有管理权限，他就可以给自己审批通过任何配方变更——那前面所有的权限设计就全白费了。
权限分类全景图
下面这张图把五种权限的关系和流转路径画出来了。你可以把它当作权限配置的参考地图：
权限之间的依赖关系
这五种权限不是孤立的。我总结了一个简单的依赖规则：
- 查看权限是其他所有权限的前提——你连看都看不到，还编辑什么？
- 编辑权限通常需要查看权限，但查看权限不一定要有编辑权限
- 审批权限与编辑权限互斥——同一个人不能既编辑又审批同一个配方
- 删除权限建议独立配置，不要跟编辑或管理权限绑定
- 管理权限是全局性的，不受其他权限约束，但操作需要留痕