设计角色、权限与数据范围

本章目标：按照真实职责建立最小必要权限，既让用户能够完成工作，也防止越权查看和操作。

1. 权限不是开发完成后的收尾项

权限会影响：

• 用户是否能看到应用入口；
• 能否创建、查看、修改和删除记录；
• 能看到本人、本部门还是全部数据；
• 能否处理流程任务；
• 能否导出和打印；
• 能否进入设计和管理功能。

如果最后才配置权限，往往会发现表单、视图和流程都建立在“所有人什么都能做”的假设上。

2. 权限设计要回答四层问题

层次	核心问题	采购案例
应用访问	谁能进入这个应用？	试点员工、主管、行政
功能对象	能使用哪些模板、视图和管理入口？	员工不能进入设计功能
业务操作	能新增、查看、修改、删除或导出吗？	申请人可新增自己的申请
数据范围	对哪些记录拥有上述能力？	申请人只看本人，主管看职责范围

具体配置可参考权限与授权概述。

3. 先设计业务角色，不要直接给每个人授权

角色代表稳定的业务职责：

• 采购申请人；
• 直属主管；
• 行政采购员；
• 行政负责人；
• 应用管理员。

角色名称应表达“负责什么”，而不是组织中某个人的姓名。

直接给个人大量授权的问题：

• 人员变动时容易漏改；
• 无法看出一个权限为什么存在；
• 相同岗位之间权限不一致；
• 工作交接困难。

角色成员管理参见应用角色管理。

4. 建立角色权限矩阵

功能/数据	申请人	直属主管	行政采购员	行政负责人	应用管理员
进入应用	是	是	是	是	是
新建申请	是	按需	按需	按需	管理需要
查看本人申请	是	是	是	是	是
查看部门申请	否	职责范围	按需	是	是
查看全部申请	否	否	是	是	是
修改草稿/退回申请	仅本人	否	否	否	管理例外
审批	否	分配任务	否	分配任务	不默认代办
登记采购结果	否	否	是	是	管理例外
导出	否或本人	按需	是	是	是
设计应用	否	否	否	否	是

“应用管理员拥有管理能力”不代表他应该日常代替业务角色处理申请。管理权限和业务责任要分开。

5. 最小权限原则

从完成职责所需的最少权限开始：

1. 先确定用户必须完成的任务；
2. 给出完成任务所需的功能；
3. 限定到所需数据范围；
4. 用目标角色账号验证；
5. 不够再增加，而不是先开放全部再逐步收回。

最小权限不仅是安全要求，也能减少界面干扰。用户看不到与自己无关的管理按钮，更容易完成工作。

6. 设计数据范围

常见范围：

本人

只看自己创建或归属自己的记录。

本部门

看当前职责范围内的部门数据。必须明确：

• 是否包含下级部门；
• 按申请发生时部门还是当前部门；
• 人员转部门后历史数据怎样处理；
• 主管职责变化后权限怎样变化。

全部

适合集中处理或管理角色，例如行政采购员和行政负责人。需要评估敏感信息和导出风险。

特定关系

例如项目负责人看自己负责项目的记录。必须有稳定、明确的业务关系，不能依赖模糊文本。

详细配置参见数据范围与行级权限。

7. 业务状态也会限制操作

即使一个人对模板拥有修改权限，也不代表所有状态都能改：

• 草稿：申请人可改；
• 审批中：申请内容只读；
• 已退回：申请人可按规则修改；
• 待采购：行政只能登记采购相关信息；
• 已完成：业务内容只读；
• 已作废：仅查看。

因此最终允许操作取决于：

角色权限 + 数据范围 + 当前状态 + 当前流程责任。

四者必须一起验证。

8. 审批权限和数据权限不是一回事

获得一条审批任务，代表该用户可以处理这项任务，不自动代表：

• 可以查看应用中所有申请；
• 可以修改申请业务内容；
• 可以导出部门数据；
• 可以进入流程设计器。

反过来，能查看一条申请也不代表能审批它。

不要为了让审批人打开单据，给他“全部数据、全部操作”权限。

9. 敏感信息和输出

对金额、个人信息、合同附件等内容，除了页面查看，还要考虑：

• 是否出现在列表预览；
• 是否能通过搜索找到；
• 是否包含在导出文件；
• 是否出现在打印件；
• 通知中是否直接展示；
• 哪些角色能下载附件。

导出后的文件脱离应用界面，传播风险更高，应单独确认权限和用途。

10. 职责分离

高风险业务可能要求不同人完成不同职责，例如：

• 申请人不能审批自己的申请；
• 执行采购的人不能单独批准高金额采购；
• 应用设计者修改关键规则后需要业务负责人确认；
• 应用管理员不应借管理权限代替所有审批人。

如果制度有职责分离要求，应写入规则和测试，而不是依靠大家“自觉不点”。

11. 角色变化和工作交接

设计时考虑：

• 新员工加入如何获得角色；
• 调岗后何时取消旧权限；
• 离职人员的当前待办由谁接手；
• 当前采购责任如何转移；
• 历史申请人和审批事实是否保持不变；
• 临时代理何时自动结束。

工作交接转移的是当前责任，不应改写历史事实。

12. 权限测试必须包含反例

申请人账号：

• 能创建申请；
• 能看自己的；
• 看不到其他人的；
• 审批中不能修改；
• 看不到应用设计入口。

主管账号：

• 能处理分配给自己的任务；
• 能看职责范围内数据；
• 不能处理不属于自己的任务；
• 不能修改申请明细。

行政账号：

• 能看已批准的待采购事项；
• 能登记采购结果；
• 不能修改申请用途和预计明细；
• 是否能导出按矩阵验证。

应用管理员账号：

• 能维护应用；
• 业务流程是否允许其代办，不能只因为“按钮可见”就判定合理。

13. 权限变更记录

重要角色和权限调整应记录：

• 谁提出；
• 为什么调整；
• 影响哪些角色和数据；
• 谁确认；
• 何时生效；
• 使用哪些测试账号验证；
• 是否需要回收旧成员权限。

14. 常见错误

• 开发时只使用管理员账号；
• 为了方便直接给所有人全部数据；
• 权限直接分给个人，没有角色依据；
• 把审批任务权限等同于全部记录权限；
• 只测试“应该允许”，不测试“必须拒绝”；
• 只限制页面按钮，不验证真实业务结果；
• 人员调岗后旧角色长期不回收；
• 导出和附件没有单独评估。

15. 本章完成标准

• [ ] 业务角色按职责定义，没有以个人命名；
• [ ] 应用、功能、操作和数据范围四层权限完整；
• [ ] 权限矩阵覆盖所有主要角色；
• [ ] 不同业务状态下的可修改范围明确；
• [ ] 审批任务和普通数据访问已经区分；
• [ ] 敏感信息、附件、导出和打印已评估；
• [ ] 工作交接不改写历史事实；
• [ ] 每个角色都有允许和拒绝两类测试。

下一步

权限完成后，还要为不同角色设计查询、输出和外部协作。下一章学习设计视图、输出、通知与外部协作。