高级权限场景4｜公共规则与变更追溯

OdooCC增强版场景课｜共同要求集中维护，配置变动能够解释

本节学习目标

理解内部用户公共角色、配置变更日志和受控JSON复用流程。

配套视频

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

在B站观看本节配套视频

演示准备

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

业务问题

企业权限不是配置一次就结束。岗位会变，规则会调整，维护人也可能交接。这个场景说明内部用户公共角色、权限变更日志，以及配置复用时的检查流程，让管理员更容易回答谁改了什么、影响了哪些用户。

操作与理解

1. 公共角色自动适用内部用户

内部用户公共角色自动适用已有和新增内部用户。共同要求可以集中维护，岗位差异继续放在普通角色里。门户用户和公众用户不纳入公共角色。本演示只查看公共角色的范围，没有给所有用户新增限制。

图：公共角色自动适用内部用户。点击图片可查看大图；业务数据均为虚构样例。

2. 岗位角色只能继续收紧

如果某项限制真的适用于全体内部用户，可以考虑公共角色。只属于销售或采购的要求，应留在岗位角色。多个角色的限制按收紧方向合并，不能靠角色排序覆盖公共限制。管理员也要谨慎，避免共同规则影响自己的业务操作。

3. 配置变化自动进入日志

进入权限变更日志，可以看到本次演示演示新建角色、添加记录范围和字段规则的记录。日志保存操作人、时间、配置模型和来源角色，方便后续定位。它记录模块配置变动，不代表能够追溯所有原生权限的外部修改。

图：配置变化自动进入日志。点击图片可查看大图；业务数据均为虚构样例。

4. 打开具体变更，查看前后快照

打开一条字段隐藏规则，可以看到操作人、目标模型、受影响用户，以及变更前后的配置快照。这样交接时可以解释，成本字段为什么在岗位界面隐藏。日志是应用内事务审计，不承诺数据库管理员级别的防篡改能力。

图：打开具体变更，查看前后快照。点击图片可查看大图；业务数据均为虚构样例。

5. 角色配置可以导出JSON

角色表单提供JSON导出入口。它适合保留配置快照，或在受控环境之间复用。用户、组、公司和字段在不同数据库中可能不同，不能把一个环境的文件直接当成另一个环境已经验收通过的权限方案。

6. 导入先测试，默认归档

导入向导提供测试导入，并默认勾选导入后归档。预检查会核对模型、字段、用户、组和公司映射。公共角色快照也不会直接覆盖目标环境的公共角色。本次演示展示入口与默认策略，未在演示环境重复导入同一套角色。

图：导入先测试，默认归档。点击图片可查看大图；业务数据均为虚构样例。

7. 权限管理需要配置、诊断和留痕

一个可持续维护的权限流程，是先明确岗位要求，再配置和诊断，最后保留变更依据。配置复用也要先检查、再验收、再启用。把这些动作组织起来，权限维护才能逐渐从个人记忆，变成企业可以交接的工作方法。

结果核对

• 公共角色面向内部用户，门户与公众用户不在其适用范围内。
• 变更日志能定位操作人、来源角色、目标模型和前后快照。
• 导入向导默认归档，先做映射检查，再在测试环境验收。

使用边界

本节只查看公共角色和导入入口，没有给全体用户新增规则，也没有执行JSON导入。日志是应用内事务审计，不承诺数据库管理员级防篡改。

动手练习

选一条已有权限变更日志，说明变更原因、受影响用户和回查路径；为跨库复用列出用户、组、公司、模型和字段映射。

老赵的实践建议

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

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