Odoo 企业版项目/帮助台互转为什么不是“复制一张单”：客户上下文、阶段路由与权限返回讲透

project_helpdesk 的重点不是双向转换按钮，而是 task 与 ticket 在客户、阶段、消息来源和返回动作上的一致性。

主要参考：

- `enterprise/project_helpdesk/wizard/project_task_convert_wizard.py`

• enterprise/project_helpdesk/wizard/helpdesk_ticket_convert_wizard.py

• enterprise/project_helpdesk/tests/test_tasks_tickets_conversion.py

  ---

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

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

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

  1. 任务转工单时，向导先决定默认 helpdesk team，再基于 team 选 stage，最后把 partner、description 写进 ticket。
  2. 工单转任务时，流程对称：先定默认 project，再按项目可用阶段定 task stage，客户上下文继续沿用。
  3. 转换完成后，原记录会被 archive，并在新旧对象上互留 origin message，使项目协作和客服协作能追同一条历史。

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

  三、最容易踩错的边界

  • 默认 project/team 都是可 override 的方法，说明业务线可以按场景定路由，而不是写死。
  • 单条转换返回 form，多条转换返回 list，这决定了一线用户看到的收尾动作。
  • partner 只迁移业务主体，不会自动把所有子联系人、附件权限一并展开。

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

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

  1. 售后项目和客服工单若经常互转，建议统一阶段命名规则，减少认知摩擦。
  2. 消息回链很重要，它决定团队能否看见“这单从哪来的”。
  3. 自定义双向转换时，先保留默认向导结构，再扩字段。

  五、结论

  task 和 ticket 互转的关键是上下文延续，不是复制字段。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。