先说结论
crm_mail_plugin 里那几条标了 deprecated 的旧路由，并不是“忘了清理的历史包袱”，而是 Odoo 故意保留的升级缓冲层。
它们分别解决三件事：
- 旧插件还需要按 partner 拉关联 leads；
- 旧插件还需要跳到一个已经预填 partner 的 lead 创建表单；
- 旧插件还需要直接打开某条 lead 的 form view。
所以这些路由的价值不在新功能，而在于：
当邮件插件版本前后不一致时，CRM 入口不能突然断掉。
一、为什么 deprecated 路由还要继续保留
crm_client.py 里几条接口都明确写了类似说明：
- 自 saas-14.3 起已不再是新版本插件所必需；
- 但为了兼容旧版本邮件插件，仍需保留。
这说明 Odoo 对插件升级这件事的判断非常现实：
- 服务器端模块可以升级；
- 但用户的 Outlook / 邮件插件扩展不一定同步更新；
- 如果你在服务端“觉得旧接口没用了”就立刻删掉，实际结果往往是大量桌面端入口直接失效。
也就是说，这些旧路由本质上是跨版本协议兼容层。
二、get_by_partner_id 为什么存在，它不是重复造轮子吗
/mail_client_extension/lead/get_by_partner_id 这个接口做的事情其实很朴素：
- 接收一个 partner；
- 调
_fetch_partner_leads()； - 返回这个 partner 相关的 leads 列表。
从新架构视角看，这当然像是旧式接口；但对旧插件来说，它非常关键，因为邮件侧的面板本来就需要一条“给我这个联系人的 CRM 线索摘要”的稳定入口。
所以它并不是纯历史遗迹，而是：
- 老客户端还在调用；
- 服务端不得不继续理解这类请求；
- 直到旧客户端足够少，才有可能真正移除。
这正是兼容迁移最典型的 trade-off：
- 代码不够“新”；
- 但产品不能为了清爽而牺牲升级路径。
三、为什么“从 partner 直接跳新建 lead”要用 server action 重定向
crm_lead_redirect_create_form_view() 并没有自己手写一个 form URL，而是：
- 先拿
lead_creation_prefilled_action； - 再把
partner_id拼进 URL； - 最终重定向到
/odoo/action-<id>?partner_id=...。
这说明 Odoo 不想把插件兼容路由写死成某个固定表单地址，而是仍然通过 action 体系接管：
- 视图是谁，由 action 决定；
- partner 预填上下文通过参数传过去；
- 后续即便表单布局变了，这层跳转语义依旧稳定。
这是一种非常典型的 Odoo 兼容方式：
旧入口继续保留，但真正的 UI 组织仍交给 action / context 体系。
四、_form_view_auto_fill() 为什么看起来简单，却是兼容桥的关键一环
模型里的 _form_view_auto_fill() 非常短，只是返回一个 act_window，并把：
default_partner_id
从 context 里的 params.partner_id 填进去。
但它的重要性恰恰在于它够短、够稳。
因为旧插件真正需要的不是一大堆业务逻辑，而只是：
- 从邮箱联系人发起；
- 打开 CRM 创建表单；
- partner 已经帮用户带好。
如果这个桥不存在，旧插件就只能：
- 自己猜测创建 URL；
- 自己构造默认值；
- 最后更容易在服务端升级后断掉。
所以 _form_view_auto_fill() 看似轻，其实承担的是把旧客户端引回标准 Odoo action 上下文的职责。
五、为什么 open 路由依旧用 form view 重定向
crm_lead_open() 做的也是类似思路：
- 找
crm.crm_lead_view_form； - 拼
/odoo/action-<action_id>/<lead_id>?edit=1； - 再重定向过去。
它的价值在于：
- 旧插件不必理解后台菜单结构；
- 只要知道 lead_id，就能被带到标准表单；
- 服务端仍保留对最终 UI 入口的掌控。
这比让插件侧持有一堆固定后台 URL 模板更稳，也更符合“客户端尽量薄”的设计。
六、为什么这类兼容接口最容易在升级时被误删
工程上常见的误区是：
- 看到 deprecated 注释；
- 搜一遍当前代码，发现新前端不再调用；
- 就觉得可以删。
但插件类系统的问题在于，调用方往往不在同一个代码仓里，也不一定同步发布。
因此判断能不能删，不能只看：
- 服务器端现在有没有用到；
还要看：
- 生产环境里的客户端是否已经完成迁移；
- 企业用户是不是还在旧版 Outlook 插件上。
Odoo 把这些接口保留下来，本质上是在给真实世界的升级节奏让路。
七、实施里最容易误判的几个点
1. 以为 deprecated 就等于可立即删除
在插件兼容场景里，这通常是错的。
2. 以为 create_from_partner 只是一个简单重定向
它实际上是在把旧入口重新导回 action/context 体系。
3. 以为 open 路由只是为了方便
它也是兼容层，避免旧客户端硬编码后台 URL。
4. 以为旧插件升级不同步不会影响服务端
恰恰相反，这正是服务端必须保留兼容桥的原因。
八、排错顺序建议
邮件插件升级后入口失效时，我建议按这个顺序查：
- 当前客户端是不是仍在调用旧路由；
get_by_partner_id是否还能返回 partner 关联线索；create_from_partner的 action 是否仍存在；_form_view_auto_fill()是否还正确接收partner_id；open路由拼出的 form view 是否可访问。
一句话记忆
Odoo CRM 邮件插件保留旧路由，不是因为舍不得删代码，而是因为升级期最怕断掉的，往往正是这种看起来“已经过时”的入口桥。
DISCUSSION
评论区