12.1 优点

1. 分层清晰

ACL、规则、字段和业务代码各自解决不同问题。理解后，绝大多数中小企业权限都能以较少配置实现。

2. 声明式、模块化

组、ACL 和规则可以随模块安装、升级和卸载；XML ID 使模块间复用稳定。相比把权限散落在每个 controller 中，更容易审查。

3. ACL 默认拒绝

新模型没有 grant 就不能访问，降低忘记配置时直接暴露模型的概率。

4. 规则进入 SQL

read/search/count 等主路径在数据库查询阶段过滤，通常比把全量记录取回 Python 再过滤更一致、更高效。

5. 组与隐含组可组合

“经理包含用户能力”等常见层级可以复用，应用模块之间也能通过 implied groups 组合能力。

6. 多公司上下文较成熟

允许公司、当前启用公司、规则和关联一致性形成协作机制；业务代码可以用 with_company() 明确切换。

7. 易于自动化验证

with_user()、with_context()、统一 check_access() 让权限逻辑可以在事务测试中直接验证，无需只靠 UI 自动化。

8. Odoo 18 继续收敛和加固

统一 check_access() 减少只查 ACL 或只查规则的误用；敏感模型 _allow_sudo_commands=False 和 x2many Command 来源 uid 恢复提高了纵深防御。

12.2 缺点与风险

1. ACL 只能加，不能减

没有显式 deny、优先级或覆盖。一条意外 grant 会让任何“限制组”失效。职责冲突应在分配阶段阻止，不能靠再加一个拒绝组修补。

2. 组规则 OR 很反直觉

很多管理员自然以为“多条规则会越来越严格”，但组规则恰恰可能越加越宽。一条 TRUE 组规则即可放宽其他组规则。

3. 技术组不等于中国企业岗位

原生组适合稳定技术能力，但没有岗位、兼岗、授权来源、公司范围、有效期、代理、审批等业务概念。把这些全部直接映射成组会导致组爆炸。

4. 用户组关系丢失来源

groups_id 中看不出直接授予、岗位映射、隐含组或临时授权的来源。撤销一个来源时难判断是否仍应因另一个来源保留。

5. 缺少 CRUD 之外的统一能力模型

确认、取消、审批、过账、导入、导出、打印分散在各模块的 Python 方法、按钮和控制器中，没有统一 capability 注册与解释。

6. 字段权限表达力有限

一套字段 groups 无法区分可读/可写，也难按状态、金额、组织关系动态判断。当前 Odoo 18 create 通用路径还需对敏感字段显式加固。

7. UI 权限语义不统一

菜单、窗口动作、报表动作、服务器动作、视图 groups 的强制程度不同。管理员很容易把“按钮看不到”当成“不能执行”。

8. 有效权限难解释

原生用户页的权限计数主要从组关联 ACL/组规则出发，不能完整解释全局规则、组规则 OR、字段权限、方法代码和 sudo。组继承来源也不可见。

9. 记录规则不是业务不变量

write 只看旧记录；负责人转移、状态变化和自批必须额外编码。规则名称再像“禁止修改”也不能代替调用时点分析。

10. safe_eval、缓存与性能门槛高

复杂 domain 难以让普通管理员正确维护；自定义求值变量若没有同步设计缓存键和失效，可能产生隐蔽越权或误拒绝。

11. 审计和治理较弱

缺少完整授权申请、审批、复核、到期回收、权限来源解释、职责分离检查和不可变审计事件。

12. 动作与报表直达边界容易遗漏

窗口/报表的 groups 主要控制入口；公开方法和自定义 controller 需要开发者主动补齐服务端授权。低代码配置越多，越需要统一审计工具。

12.3 应如何评价这些缺点

这些并不说明 Odoo 原生权限“设计失败”。它是一套面向模块化 ERP 的通用底座，刻意把复杂业务政策留给具体模块。真正的问题通常来自两种错位：

1. 把技术底座误当成完整的企业 IAM/内控平台。
2. 没理解底层组合语义，就在其上继续堆组和规则。

合理的增强方向是保留原生 ORM 安全链，在上面增加业务角色、组织范围、能力、审批、解释和审计，而不是轻易重写全部 ir.rule 语义。