Odoo 企业版工单转商机为什么 team 和负责人不是简单复制：helpdesk team 配置、partner 默认值与 action 返回讲透

crm_helpdesk 真正难的不是“把 ticket 变成 lead”，而是决定客户、销售团队、负责人和返回动作该跟谁走。

主要参考：

- `enterprise/crm_helpdesk/wizard/helpdesk_ticket_to_lead.py`

• enterprise/crm_helpdesk/models/helpdesk_ticket.py

• enterprise/crm_helpdesk/tests/test_crm_helpdesk.py

  ---

  一、这不是单模块按钮，而是一条跨模块链路

  很多人把这个功能理解成某个界面上的一个按钮、一个 smart button，或者一次自动创建。但从源码看，真正重要的是：上游对象先保留业务上下文，中间层做状态/域/权限判断，下游对象再接住这个上下文继续工作。只看最后一个界面动作，很容易把问题看窄。

  二、核心跨链路是怎么跑通的

  1. 向导先根据 ticket 内容决定 action：匹配到客户则 exist，没客户但有标题则 create，否则 nothing。
  2. team 计算先看 ticket user，再用 _get_default_team_id(user_id=...) 反推合适的 sales team，随后才决定 salesperson 是否可继承。
  3. 真正创建 lead/opportunity 后，ticket 的 description、email_cc、campaign、medium、source 会一起进入 CRM，保持营销上下文连续。

  这就是为什么我把它归类为“跨模块链路”题：这里至少同时牵涉了业务对象、会计/项目/销售对象，以及状态或权限判断，而不是单个模型内部的小机制。

  三、最容易踩错的边界

  • 归档工单不能再转换，防止重复建 lead。
  • message thread 与附件会迁到新 lead，原 ticket 再补一条回链消息，但如果当前用户无权读取 lead，系统会把你送回 ticket。
  • 是否创建 lead 还是 opportunity，还受当前用户是否拥有 crm.group_use_lead 影响。

  这些边界决定了数据是否还能回到正确的模块继续流动。如果边界被自定义绕开，后面最常见的结果就是：报表看起来还能出， drill-down 却已经解释不通。

  四、落地时最值得先验的三件事

  1. helpdesk team 和 sales team 的人员映射要先配好，否则默认负责人经常落空。
  2. 如果客服经常把同一客户问题升级成销售机会，先检查 _find_matching_partner() 命中率。
  3. 对话历史是升级成功的关键，别在自定义里把 message_change_thread() 删掉。

  五、结论

  ticket 转 lead 的难点是路由，不是复制标题。team、owner、partner 和返回动作要一起判断。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。