企业 OA 的权限不仅是“能不能打开某个菜单”。用户可能有页面访问权限，却不应看到其他部门的合同；也可能可以查看项目，却不能修改任务。把菜单、操作和数据范围混为一谈，权限规则很快会变得难以维护。
拆成三层授权
- 菜单权限：决定用户能否进入工作台、审批、客户或项目等模块。
- 操作权限：决定能否新增、编辑、审核、导出或删除具体记录。
- 数据范围：决定用户能看哪些部门、本人负责或参与的业务数据。
组织部门、岗位、角色与用户应分别建模。岗位描述职责，角色聚合权限，组织关系用于数据范围；一个人可拥有多个角色，但最终权限需要按清晰规则合并。
在服务端统一执行数据范围
列表、详情、导出和统计接口都应走同一套数据范围条件，不能只在页面按钮上隐藏功能。对“本人、所在部门、部门及下级、全部”等范围，先把规则转成可测试的查询条件，再应用到每个业务入口。详情页也要重新校验记录权限，防止通过猜测 ID 绕过列表限制。
保持可审计、可回收
角色授权变更记录操作者和变更内容；离职或调岗时优先停用账号并迁移业务归属，不要直接删除仍被合同、审批引用的用户。测试时至少覆盖跨部门访问、越权导出、禁用账号、多个角色叠加和管理员最小授权。权限清晰，比不断追加特例更容易长期维护。
