企业官网建设流程全解析

简介：本资源是一款专为Odoo 17定制的轻量级安全插件，面向使用Odoo进行CRM系统部署的中高级开发者与企业IT管理员，解决销售团队数据权限管控难题——确保普通销售人员仅能查看其名下分配的联系人，兼顾隐私合规与业务灵活性。插件基于Odoo原生记录规则机制实现，核心逻辑封装在2个Python文件（init.py与__manifest__.py）中，权限策略通过1个XML文件（salesperson_contact_rule.xml）定义，另含编译缓存及系统隐藏文件，共5个文件，总大小仅3KB，即装即用。目前已有356人学习下载，适合快速集成至现有Odoo 17环境。读者可直接部署该插件，获得开箱即用的数据隔离能力：既限制普通销售用户仅见user_id匹配的联系人，又保留其查看未分配联系人的权限以承接新线索，同时确保管理员角色不受限制，完整覆盖多角色权限分级管理场景。

1. Odoo 17插件实战：销售人员仅查看自己联系人——不是靠权限组硬砍，而是用记录规则动态过滤

你有没有遇到过这种场景：销售团队抱怨“为什么我能看到隔壁组的客户线索？这不合规”，而IT同事翻遍Odoo内置权限组，发现“销售员”角色默认就能读取全部联系人（res.partner）；强行禁用“读取全部”又导致报价单、订单里关联客户失败——系统直接报错。这不是配置疏漏，是Odoo权限模型的底层设计逻辑：全局权限控制访问能力，记录规则（Record Rules）才决定你能看到哪些具体数据。本篇拆解的这个Odoo 17插件，核心就做一件事：在不改任何原生模块、不碰用户组权限的前提下，通过一条精准的域表达式（domain），让每个销售员登录后，所有视图（列表、表单、搜索框）自动只显示user_id等于当前用户的联系人。它不依赖自定义字段、不修改core代码、不引入第三方依赖，纯Odoo原生机制实现，部署后重启服务即可生效。适合正在用Odoo 17做CRM落地、需要快速满足销售数据隔离要求的中小团队——尤其当你已经上线但突然被审计提出“客户数据最小权限原则”时，这比重配权限组快3倍。

2. 插件结构解析：为什么必须用ir.rule而非重写search方法

2.1 插件目录结构与核心文件职责

该插件采用标准Odoo模块结构，共5个关键文件，无冗余代码：

salesperson_partner_isolation/ ├── __init__.py # 声明models导入路径 ├── __manifest__.py # 模块元信息：name/description/depends等 ├── models/ │ └── __init__.py # 导入res_partner_rule.py │ └── res_partner_rule.py # 核心：定义记录规则模型（继承ir.rule） ├── security/ │ └── ir.model.access.csv # 空文件（不开放rule管理权限给普通用户） └── data/ └── record_rule_data.xml # XML数据文件：注册规则到数据库

提示：此插件刻意不提供security/groups.xml，因为目标是“对现有销售组透明生效”，而非新建权限组。所有改动都收敛在ir.rule这一层。

2.2 为什么选ir.rule而不是重写search方法？

新手常误以为“重写res.partner的search()方法加user_id = uid条件”更直接。但这是典型踩坑点：

• 视图层失效：Odoo列表页（tree view）的分页、搜索、分组功能均绕过search()，直接走ORM底层查询，重写search()对这些场景无效；
• 关联字段崩坏：当销售员创建报价单（sale.order）时，客户选择框（many2one）会触发res.partner的name_search()，该方法不调用search()，导致下拉列表仍显示全部客户；
• 性能灾难：每次search()都手动拼user_id = uid，无法利用数据库索引，10万联系人时列表加载超5秒。

而ir.rule是Odoo的查询拦截器：它在ORM生成SQL前注入WHERE条件，覆盖search()、name_search()、视图渲染、API读取等所有数据入口。实测对比：同一环境开启规则后，销售员列表页加载从4.2s降至0.3s（因数据库能走user_id索引）。

2.3 记录规则的核心域表达式：[('user_id', '=', user.id)]

record_rule_data.xml中定义的关键规则如下：

<record id="rule_salesperson_own_partners" model="ir.rule"> <field name="name">Salesperson: Own Partners Only</field> <field name="model_id" ref="base.model_res_partner"/> <field name="domain_force">[('user_id', '=', user.id)]</field> <field name="groups" eval="[(4, ref('sales_team.group_sale_salesman'))]"/> <field name="perm_read" eval="1"/> <field name="perm_write" eval="1"/> <field name="perm_create" eval="1"/> <field name="perm_unlink" eval="0"/> </record>

• domain_force是灵魂：user.id是Odoo上下文自动注入的当前用户ID，'user_id'是res.partner模型中存储负责人ID的字段（Odoo 17默认存在，无需额外添加）；
• groups指定仅对销售员组生效，不影响管理员、财务等其他角色；
• perm_unlink=0禁止删除——避免销售员误删他人客户，符合数据安全基线；
• 注意：user_id字段必须为Many2one('res.users')类型，若你的实例中客户负责人存为char字段（如salesperson_code），此规则无效，需先迁移数据。

3. 部署与验证：三步完成，但必须检查这四个隐藏状态

3.1 安装插件的标准流程

1. 将插件文件夹复制到Odoo addons路径（如/odoo/addons/）；
2. 以管理员身份登录，进入设置 → 技术 → 应用 → 更新应用列表；
3. 在应用列表中搜索Salesperson Partner Isolation，点击安装。

注意：安装过程不重启服务，但规则生效需清除缓存。执行sudo service odoo restart或在开发者模式下按Ctrl+Shift+R强制刷新浏览器。

3.2 验证规则是否真正生效的四个必查点

不能只看列表页！以下四点任一失败即说明规则未正确加载：

3.3 关键参数调试：如何临时关闭规则快速定位问题

当验证失败时，不要反复重装插件。直接在数据库中禁用规则：

UPDATE ir_rule SET active = false WHERE name = 'Salesperson: Own Partners Only';

然后刷新页面——若此时销售员能看到全部客户，证明规则本身逻辑正确，问题出在domain_force或groups配置；若仍看不到，则是前端缓存或用户组权限问题。血泪经验：80%的“规则不生效”案例，根源是销售员未被正确分配到sales_team.group_sale_salesman组（检查用户 → 编辑用户 → 所属组）。

4. 避坑指南：五个真实翻车现场与根治方案

4.1 现象：销售员列表页为空，但数据库确认其有负责客户

原因：res.partner中user_id字段为空（NULL）的记录，默认不匹配[('user_id', '=', user.id)]，且Odoo规则对NULL值默认拒绝访问。
解决：在安装插件前，运行SQL补全空值（假设销售员A的ID为123）：

UPDATE res_partner SET user_id = 123 WHERE id IN (1001, 1002, 1003) AND user_id IS NULL;

玄学提醒：Odoo 17中，新创建的联系人若未手动指定负责人，user_id默认为NULL。建议在res.partner表单视图中将user_id设为必填字段。

4.2 现象：销售员能创建新联系人，但保存后立即消失

原因：新建联系人时未赋值user_id，导致插入数据库后user_id=NULL，规则将其过滤掉，用户以为“保存失败”。
解决：在res.partner模型中重写create()方法（仅限本插件内），强制绑定当前用户：

# models/res_partner_rule.py from odoo import models, api class ResPartner(models.Model): _inherit = 'res.partner' @api.model def create(self, vals): if not vals.get('user_id') and self.env.user.has_group('sales_team.group_sale_salesman'): vals['user_id'] = self.env.user.id return super().create(vals)

注意：此代码需放在插件models/目录下，并在__init__.py中导入，否则不生效。

4.3 现象：销售经理能看到全部客户，但下属销售员看不到经理创建的客户

原因：经理创建客户时，user_id被设为其自身ID，而非下属ID。规则严格按user_id匹配，不支持“上级可见下级数据”。
解决：若需经理视角，不要修改规则，而是为经理组单独添加一条宽松规则：

<!-- data/record_rule_data.xml --> <record id="rule_manager_see_all_partners" model="ir.rule"> <field name="name">Manager: See All Partners</field> <field name="model_id" ref="base.model_res_partner"/> <field name="domain_force">[(1, '=', 1)]</field> <field name="groups" eval="[(4, ref('sales_team.group_sale_manager'))]"/> <field name="perm_read" eval="1"/> </record>

关键逻辑：(1, '=', 1)是恒真条件，确保经理组不受限制。两条规则并存时，Odoo取并集（OR），非交集。

4.4 现象：启插件后，销售员无法在报价单中选择客户（下拉为空）

原因：res.partner的name_search()方法被规则拦截，但name_search默认查询name字段，而user_id条件导致无匹配。
解决：在res.partner模型中扩展name_search，显式加入user_id条件：

@api.model def name_search(self, name='', args=None, operator='ilike', limit=100): args = args or [] if self.env.user.has_group('sales_team.group_sale_salesman'): args += [('user_id', '=', self.env.user.id)] return super().name_search(name, args, operator, limit)

避坑点：此方法必须放在插件的models/res_partner_rule.py中，且继承res.partner，否则Odoo找不到重写。

4.5 现象：插件安装后，管理员也受规则限制（看不到全部客户）

原因：ir.rule的groups字段配置错误，将管理员组意外包含在内（如ref('base.group_system')被误加）。
解决：检查record_rule_data.xml中<field name="groups">的eval值，确保仅包含销售员组。管理员不受任何规则影响，因其拥有superuser权限，Odoo会跳过所有ir.rule检查。

5. 进阶技巧：让规则适配多维度隔离（区域/产品线/客户等级）

5.1 场景升级：销售员不仅按user_id隔离，还需按“销售区域”二次过滤

假设公司按华东、华北划分销售区域，且res.partner已增加region字段（selection类型）。此时单靠user_id不够，需组合条件。修改domain_force为：

<field name="domain_force">[('user_id', '=', user.id), ('region', '=', user.region)]</field>

但user.region不存在——需先在res.users模型中添加region字段，并在用户编辑页暴露：

# models/res_users.py from odoo import models, fields class ResUsers(models.Model): _inherit = 'res.users' region = fields.Selection([ ('east', '华东'), ('north', '华北'), ('south', '华南') ], string='Sales Region')

关键细节：user.region在域表达式中可直接使用，Odoo会自动关联res.users表。无需写user_id.region。

5.2 动态规则：根据客户等级（VIP/普通）调整可见范围

若VIP客户需销售经理和对应销售员共同查看，可构建“或条件”规则：

<field name="domain_force">['|', ('user_id', '=', user.id), '&', ('is_vip', '=', True), ('manager_id', '=', user.id)]</field>

此表达式含义：user_id匹配或（是VIP且manager_id匹配）。需确保res.partner有is_vip（boolean）和manager_id（many2one）字段。

5.3 规则优先级实战：当多个规则冲突时，Odoo如何决策？

Odoo对同一模型的多条规则，采用OR逻辑合并（非AND）。例如：

• 规则A：[('user_id', '=', user.id)]（销售员）
• 规则B：[('is_public', '=', True)]（公开客户）
  则销售员看到的数据 = 其负责客户OR所有公开客户。
  若需AND效果（如“仅看自己负责的VIP客户”），必须合并为单条规则：[('user_id', '=', user.id), ('is_vip', '=', True)]。

血泪教训：曾有个项目因误建两条规则，导致销售员意外看到全公司VIP客户，审计时被定为高危漏洞。从那以后我每次加新规则，都强制用psql查ir_rule表，确认domain_force字段是单条完整表达式。

5.4 性能优化：为user_id字段添加数据库索引

规则生效后，所有res.partner查询都会带WHERE user_id = ?，若数据量超5万，必须加索引：

CREATE INDEX idx_res_partner_user_id ON res_partner (user_id);

在__manifest__.py中声明：

'data': [ 'data/record_rule_data.xml', 'data/ir_model_constraint_data.xml', # 新增索引定义文件 ],

并在data/ir_model_constraint_data.xml中写：

<function model="ir.model.constraint" name="_add_sql_constraint"> <value>res_partner</value> <value>idx_res_partner_user_id</value> <value>CREATE INDEX idx_res_partner_user_id ON res_partner (user_id);</value> </function>

验证方法：执行EXPLAIN SELECT * FROM res_partner WHERE user_id = 123;，输出中出现Index Scan using idx_res_partner_user_id即成功。

希望帮到你。

本文还有配套的精品资源，点击获取