Odoo 企业版 Helpdesk Mail Plugin 为什么不是“在 Outlook 里建单”而已：联系人侧栏、create 权限门槛与 acknowledgement 链路讲透

很多人把 Helpdesk Mail Plugin 理解成“在 Outlook 或邮箱插件里一键建单”。但从 /home/ubuntu/odoo-temp/enterprise/helpdesk_mail_plugin 看，官方做的其实是一整套邮件上下文到客服上下文的收口设计。

参考入口：

• enterprise/helpdesk_mail_plugin/controllers/helpdesk_client.py
• enterprise/helpdesk_mail_plugin/controllers/mail_plugin.py
• enterprise/helpdesk_mail_plugin/tests/test_helpdesk_client.py

一、联系人侧栏先展示 ticket 摘要，不是先暴露新建按钮

_get_contact_data() 会在父类返回的联系人信息上追加 tickets，但前提是当前用户对 helpdesk.ticket 有 create 权限。这个设计很妙：如果根本没权限建单，插件侧就直接不展示这块能力，体验上像“没安装 Helpdesk”，而不是给你一个点了就报错的入口。

所以插件不是把所有能力都硬塞到邮箱里，而是按权限裁剪成真正可用的侧栏。

二、ticket 摘要只抓少量、可判断开闭的关键字段

_fetch_partner_tickets() 默认只取 5 条，并返回：

• ticket_id
• name
• fold

这说明插件侧的目标不是把 Helpdesk 整个搬进邮箱，而是让坐席快速知道：这个联系人是不是已有 case、工单标题是什么、是否已经关闭。

三、为什么建单接口不依赖默认值自动推断

/mail_plugin/ticket/create 创建工单时，明确传了 team_id = _default_team_id()，注释还专门说：不要依赖默认值，因为要触发 acknowledgement email，并让 create 方法按 team 判 stage。

这行注释非常关键。它告诉我们：在邮箱里建单不是简单写一条记录，而是要尽量走 Helpdesk 正常入口，让阶段判定、通知模板、自动回执都按标准流程发生。

四、with_company(partner.company_id) 的意义

建单时显式切到 partner.company_id，避免插件用户当前公司上下文与联系人公司不一致时把 ticket 建错域。邮件插件场景很容易跨客户、跨公司来回切，如果不在入口收口，多公司数据就会被悄悄串掉。

五、日志白名单和翻译白名单也被扩展

_mail_content_logging_models_whitelist() 与 _translation_modules_whitelist() 都在有 create 权限时把 helpdesk.ticket 与 helpdesk_mail_plugin 加进去。这些小扩展看起来不起眼，但它们保证了插件里的内容记录与文案翻译能把 Helpdesk 当成一等集成对象，而不是旁路模块。

六、实战建议

• 如果插件里看不到 ticket 区块，先查 create 权限，而不是先查前端 bug。
• 若建单后没有自动 acknowledgement，先检查 team_id 是否真的按 Helpdesk 入口传入。
• 多公司场景务必确认 partner 的公司归属，否则邮件里建单最容易串账。

七、结论

helpdesk_mail_plugin 不只是“在邮箱里建单”，而是把联系人、权限、团队默认值、自动回执和多公司上下文收成一条标准化入口。它解决的是邮件场景下如何安全复用 Helpdesk 主链路。