Odoo13 归档res.partner私有员工访问规则后普通用户报AccessError问题

核心逻辑前置说明 #

你计划归档的res.partner.rule.private.employee（即匹配域为['|', ('type', '!=', 'private'), ('type', '=', False)]的默认规则）并非用于限制普通用户查看私有联系人的排斥类规则，而是Odoo默认给普通员工组配置的访问白名单兜底规则：它的匹配域作用是允许普通用户读取所有非私有、未设置类型的公共联系人，和其余细分的客户访问规则叠加后，形成完整的权限覆盖网。直接归档该规则会直接造成权限覆盖缺口，这是后续连续触发权限报错的核心诱因。

具体排查步骤 #

• 第一步：梳理全量已激活的res.partner模型记录规则
  开启开发者模式后进入「设置 > 技术 > 记录规则」，筛选模型为res.partner、状态为已激活的所有规则，核对两条核心信息：
  1. 所有分配给base.group_user普通员工组的允许类规则，其domain取并集后的范围，是否能覆盖两个报错场景的基础访问需求：创建客户时系统需要读取的公共关联数据（如国家、行业标签）、个人中心页面需要读取的当前登录用户关联的私有联系人记录
  2. 确认规则的应用组配置是否正确——部分场景下你以为归档的是某条规则，实际加载到权限计算流程的规则因为组配置错误，根本没有被普通用户组匹配到
• 第二步：精准定位报错对应的具体访问对象
  给复现报错的普通用户临时开启调试模式，系统弹出的AccessError会明确标注被拦截的模型和记录ID，根据记录属性定位缺口：
  • 若被拦截的是和当前登录用户绑定的、type='private'的联系人记录，说明当前权限集合完全没有覆盖用户自身的档案访问需求
  • 若被拦截的是公共属性的基础数据类联系人，说明你保留的「普通用户查看自己名下客户」的窄范围规则，完全没有将系统运行依赖的公共数据纳入允许范围
• 第三步：核对规则计算的实际结果
  断点调试时不要直接在规则入口打断点，要在权限计算流程的最后节点，打印当前用户在res.partner模型上最终解析出的全局允许domain，对比实际需要访问的记录是否在该domain覆盖范围内——多数排查卡点都是因为规则叠加后的并集范围远小于预期，而非单条规则逻辑写错。

可直接落地的修复方案 #

• 不要全量归档原兜底规则，正确的调整逻辑是将原规则的domain和你自定义的「用户查看自己名下客户」的规则做合并，而非直接删除：既保留对公共非私有联系人的基础访问权限，又叠加自有客户的查看范围，避免出现权限缺口
• 针对个人中心的访问报错，单独新增一条所有员工组的允许规则，domain为[('user_ids', 'in', user.id)]，专门放开当前用户对自身关联联系人的读取权限，该规则不会扩大客户数据的可见范围，仅能保证用户访问自己的档案页面
• 针对创建客户的访问报错，单独为公共基础数据类的联系人（如国家、公共行业标签）新增一条全员可读的允许规则，不要将这部分系统运行依赖的基础数据纳入私有客户的权限管控范围
• 避坑提示：Odoo同一模型下、同组的允许类记录规则是取并集计算最终权限的，删除一条兜底的宽范围允许规则，哪怕补充了新的窄范围允许规则，整体权限覆盖范围也会大幅收缩，完全达不到预期的权限调整效果。

内容的提问来源于stack exchange，提问作者koneq