导言
当用户尝试查看或操作某条记录却没有足够权限时，Odoo 会在界面上弹出“访问被拒绝”提示并阻止后续操作。这不是程序崩溃，而是权限层面在保护数据。
常见的提示形式包括：
Access Denied
You are not allowed to access this document.
与低级的 AccessError 比较，Access Denied 更偏向面向用户的界面提示，通常由 UI 层直接触发。
本指南将解释导致该错误的典型原因，并给出不削弱系统安全性的正确修复方法。
为什么会出现 Odoo 的“访问被拒绝”？
Odoo 通过多层机制来控制访问：
- 用户组（Groups）
- 访问控制列表（ACL）
- 记录规则（Record Rules）
- 多公司权限限制
只要其中任一层阻断了权限，系统就会显示“访问被拒绝”。
这种情况最常在界面操作时发生，典型场景包括：
- 打开一条记录
- 编辑记录
- 确认或验证单据
- 删除记录
导致 Odoo 显示“访问被拒绝”的常见原因
1. 用户缺少必要的用户组
用户可能没被分配到对某个业务对象具有访问权的安全组。
举例说明：
销售人员尝试查看或修改会计分录，但没有会计相关组的权限。
2. 记录规则把这条记录过滤掉了
记录规则通过 domain 条件决定用户能看到哪些记录。
举例说明：
例如：[('user_id', '=', user.id)] 之类的条件会只允许看到与当前用户相关的记录。
当记录不满足规则时，用户在界面上根本看不到这条记录。
3. 多公司限制
如果某条记录属于另一家公司，当用户当前上下文公司与记录所属公司不一致时会被屏蔽。
在启用多公司环境的实例中，这类问题特别常见。
4. 继承权限冲突
用户属于多个组且这些组的权限设置相互覆盖或冲突时，可能会出现意外的访问限制。
5. 自定义模块引入的安全规则
第三方或内部开发的模块有时会增加过于严格或有误的记录规则/ACL，从而无意中阻断正常访问。
修复 Odoo 访问被拒绝问题的步骤
步骤 1 — 检查用户所属的组
路径：
设置 → 用户与公司 → 用户
查看该用户被分配了哪些安全组。
确认用户是否拥有目标模型所需的访问组。
步骤 2 — 查看访问控制列表（ACL）
路径：
设置 → 技术 → 安全 → 访问控制列表
确认相关组对该模型是否拥有读取/写入/创建/删除的权限。
步骤 3 — 检查记录规则
路径：
路径：
设置 → 技术 → 安全 → 记录规则
审阅针对该模型的 domain 过滤条件，必要时临时禁用可疑规则以定位问题点。
步骤 4 — 用管理员账号测试
如果管理员能访问但普通用户不能，说明问题出在权限配置层面而非数据本身。
步骤 5 — 核对公司上下文
切换用户的公司上下文并再测试一次，确认是否为公司归属导致的访问限制。
属于其他公司的记录在不同公司上下文下会被屏蔽。
如何预防访问被拒绝出现
- 保持记录规则设计简单并做好文档记录。
- 避免叠加过多或过于苛刻的 domain 过滤条件。
- 在非管理员账号上测试所有安全变更以验证真实效果。
- 定期审计多公司配置，确保公司切换规则符合业务预期。
- 安装新模块后务必回顾安全设置，防止引入冲突规则。
Odoo 中的安全机制应在保护数据与可用性之间取得平衡，既要防止越权，也要保证业务流程顺畅。
Dasolo 是如何设计平衡的权限模型的
很多时候‘访问被拒绝’源自安全规则与实际业务流程未对齐。适当收紧权限固然必要，但过度苛刻的规则会把正常操作也挡在门外。
在 Dasolo，我们定位访问问题时，会全面检查以下几方面的相互作用：
- 安全组及其继承关系
- 记录规则与 domain 过滤器
- 多公司可见性约束
- 自定义模块对默认权限的覆盖
- 用于系统集成的技术用户权限设置
我们的做法不是简单放宽权限，而是根据业务角色和数据归属建立既安全又易用的权限模型。通过这样的对齐，可以在不牺牲安全性的前提下大幅减少“访问被拒绝”的复发。
结语
总结：Odoo 的“访问被拒绝”发生在用户没有访问或修改某条记录所需的权限时。表面上的提示看似简单，但根源常常是用户组配置不当、记录规则过严或多公司设置冲突。
逐项检查用户角色、校验安全配置并确保权限层与业务流程一致，是解决此类问题的关键。建立清晰、可维护的权限模型不仅能消除反复出现的访问冲突，也有助于长期的数据治理与安全管理。