高级权限场景1｜按岗位统一管理权限

OdooCC增强版场景课｜用业务岗位组织授权与限制

本节学习目标

理解访问角色如何把人员、原生业务组和附加限制组织为业务岗位。

配套视频

配套视频已安排于 2026-10-22 09:00（北京时间） 公开。上线前播放器可能暂不可播放，可先学习下方完整图文。

在B站观看本节配套视频

演示准备

使用已安装相应模块的演示或测试环境，准备截图所示的虚构业务样例。配置操作由具备相应权限的管理员或维护人员进行；日常使用与结果验收再按实际岗位账号核对。界面以本次演示为例，不同版本与配置下入口可能有所不同。

业务问题

新员工入职时，管理员要配置菜单、业务组和操作限制。如果这些设置分散在不同入口，就容易漏项，也难以解释为什么某个人有某项权限。高级权限模块用访问角色，按业务岗位集中组织这些配置。

操作与理解

1. 建立销售岗位的演示角色

这里新建了一个销售岗位演示角色，只绑定演示申请人。角色还可以设置公司范围，并记录职责和维护边界。演示在本地环境完成，不涉及真实企业账号。实际项目应先明确人员、公司和业务责任，再设置角色。

图：建立销售岗位的演示角色。点击图片可查看大图；业务数据均为虚构样例。

2. 原生业务组负责授权

角色可以绑定原生销售业务组。演示选择了销售用户的所有单据业务组，基础授权仍然遵循Odoo原生机制。OdooCC的字段、记录范围和操作限制，是在这层授权之上继续收紧，不能把限制开关当成新的授权。

图：原生业务组负责授权。点击图片可查看大图；业务数据均为虚构样例。

3. 通用限制集中维护

角色的通用限制页提供只读、导入导出和沟通入口等设置。这个演示选择隐藏导出，说明一个岗位要求怎样集中维护。真正上线前，应逐项核对该岗位需要什么操作，不能为了省事把所有开关都打开。

4. 组授予来源可以追踪

组授予来源页能看到用户、原生业务组，以及分配前是否已拥有该组。演示申请人的销售业务组由这个角色授予。这样的来源台账，有助于后续岗位调整时解释权限变化，减少凭经验手工增删用户组。

图：组授予来源可以追踪。点击图片可查看大图；业务数据均为虚构样例。

5. 多岗位时，授权与限制分别合并

同一个用户可以承担多个岗位。原生业务组按照授权语义组合，角色限制则按收紧方向合并。一个角色禁止的操作，不能靠给另一个角色更高排序放开。严格记录范围也会取交集，因此兼岗配置必须一起核对。

6. 停用岗位角色，需要精确回收

岗位角色停用或移除成员时，模块按授予来源回收由该角色独占授予的业务组，并保护用户原先拥有的组。实施时仍需要检查其他角色和原生组的组合。本次演示演示采集完成后，已停用新增角色，恢复演示账号。

7. 用角色管理岗位，用诊断解释结果

统一角色的价值，不只是减少配置入口，还在于能够说明成员、授权和限制的来源。配置完成后，可以从模型权限运行目标用户诊断，再做真实用户业务验收。这样岗位调整更容易交接，也更容易发现权限组合中的问题。

图：用角色管理岗位，用诊断解释结果。点击图片可查看大图；业务数据均为虚构样例。

结果核对

• 演示角色只绑定演示申请人，原生销售业务组负责基础授权。
• 组授予来源能解释哪些授权来自角色、哪些原先就存在。
• 多角色限制按收紧方向组合，不能靠排序放开另一个角色的限制。

使用边界

本次演示角色采集完成后已停用，并非当前线上企业岗位。原生组授权与角色限制需要一起验收，不能只看角色表单。

动手练习

在测试库列出一个销售岗位需要的模型操作、公司范围和禁止操作，先整理清单，再给一个专用测试账号配置角色。

老赵的实践建议

先明确岗位职责，再配置、诊断和验收，最后保留变更依据。权限方案要能解释来源、验证效果，并能够交接维护。

如需体验本节场景，可通过OdooCC官网“服务与合作”联系老赵领取演示账号。