Odoo 企业版网站客服：Livechat 一键转工单的真实链路

客服最怕的不是工单太多，而是聊天里明明已经讲清楚了，转工单时却还要再复制一遍标题、附件和客户信息。

这篇文章主要参考了以下企业版源码入口：

• enterprise/website_helpdesk_livechat/models/discuss_channel.py
• enterprise/website_helpdesk_livechat/models/helpdesk_ticket.py
• enterprise/website_helpdesk_livechat/views/helpdesk_ticket_attachment_template.xml

一、这篇功能真正解决什么问题

website_helpdesk_livechat 解决的不是“在聊天窗口里多一个命令”这么简单，而是把即时沟通沉淀成可追踪工单。如果没有这层桥接，客服往往会遇到三个问题：聊天内容散在会话里、客户身份不稳定、后续团队没人接手。

这个模块的设计重点很明确：聊天仍然是聊天，但当客服输入 /ticket 标题 时，系统要把当前会话里的事实一次性整理成 helpdesk.ticket，而不是只建一个空壳单子。

二、核心链路怎么走

1. /ticket 命令先在聊天模型里完成上下文拼装

discuss.channel.execute_command_helpdesk() 会先解析命令参数，再从频道参与者里选出客户对象，同时搜索启用了 use_website_helpdesk_livechat 的 helpdesk team。也就是说，工单不是凭空创建，而是带着“从哪个聊天来、客户是谁、该落到哪个团队”的上下文一起生成。

2. 工单正文直接继承聊天历史，附件也会搬运

建单时，description 不是一段模板文案，而是 _get_channel_history() 返回的聊天历史。更关键的是，源码会把当前会话消息里的非图片附件复制到 helpdesk.ticket，并改写 res_model/res_id。这一步很实用：报错日志、合同 PDF、导出的 CSV 都会跟着工单走，后续排障不需要再回聊天记录里翻。

3. 工单和聊天会保持可回跳关系

helpdesk.ticket 上新增了 origin_channel_id，并在 action_open_livechat() 里通过 bus/store 通知前端重新打开聊天窗口。于是客服不是从聊天“跳到另一个系统”，而是在工单与会话之间来回切换，形成一条完整处理链。

三、新手最容易踩的坑

• 以为任何人都能把任意频道挂到工单上。实际上 create() 和 write() 都会检查当前用户是否对 origin_channel_id 有读取权限。
• 以为工单会自动继承所有附件。源码明确只复制非图片附件，图片仍然更偏向保留在聊天语境里。
• 以为只要装模块就能正确分单。若 team 没启用 use_website_helpdesk_livechat，命令虽然能跑，但分流体验会很差。

四、实战落地时最该盯的点

• 先确认网站客服团队是否真的启用了 livechat 桥接，否则 /ticket 只是在“建单”，不是“自动归队”。
• 再检查聊天参与者里是否能稳定识别客户；如果频道里没有有效客户对象，后续 SLA、邮箱回信和客户画像都会变弱。
• 最后核对附件类型。很多企业现场会误以为“截图没过去是 bug”，但源码本身就故意把图片排除在复制逻辑之外。

五、结论

Livechat 转工单的价值，不是少打一遍标题，而是把聊天历史、客户身份、团队归属、附件证据和回跳关系一次串起来。只有这几件事同时成立，网站客服才算真正从“即时响应”进入“可运营交付”。