论坛转工单最容易被低估，因为界面上只像一个按钮：从问题页创建 ticket，或者把 ticket 共享回论坛。源码里真正处理的是三条边：这个帖子属于哪个 forum、这个问题可以交给哪些 helpdesk team、创建后用户应该回哪里。
主要参考源码：
enterprise/website_helpdesk_forum/wizards/helpdesk_ticket_select_forum.pyenterprise/website_helpdesk_forum/controllers/website_forum.py
一、论坛不是全站任意转，team 范围先被过滤
控制器 create_ticket_and_view() 不会把所有帮助台团队都丢给访客。它先按 website_id 和 forum 与 team 的关系做分组，只有当前网站、当前论坛能接住的问题，才会出现在候选 team 里。
这意味着论坛转工单不是“前台发起一个 create”，而是先经过网站维度的 team 裁剪。
二、反向分享 ticket 时，论坛也不是随便选
向论坛共享工单时，wizard 的 action_confirm_selection() 会调用 ticket 的 _share_ticket_on_forums()。而 _create_forum_post() 又会先 team_id._ensure_help_center_is_activated()，保证目标团队真的开了帮助中心，再创建 forum post，并把原 ticket 关联进去。
这里至少有三类对象被一起串住：
- helpdesk.ticket
- forum.post
- helpdesk.team / website_forum_ids
三、为什么这不是简单复制内容
wizard 会把 ticket 名称、描述和标签映射到论坛帖子，但不代表它们从此脱钩。帖子里仍带着 ticket_id，回答也可能继续沿同一 ticket 反向关联。
所以它更像“问题在 forum 与 helpdesk 之间切换承接面”，而不是单向复制一份文本。
四、回跳边界为什么重要
一个很容易忽略的点是：用户在论坛里点“创建工单”后，期望回到能继续处理问题的界面；客服把 ticket 共享到论坛后，也需要能直接打开帖子。action_create_view_post() 就是显式让共享动作落到“创建并查看论坛贴”，而不是只关 wizard。
这类回跳如果处理不好，会出现：
- 帖子创建了，但客服找不到外部讨论入口；
- 用户能建工单，却被送到无权访问的 team；
- 跨网站论坛时问题被路由到错误帮助台。
五、结论
网站论坛转工单不是“点个按钮复制帖子”，而是forum -> team -> ticket -> forum return path 的闭环。team 过滤保证问题不会跨网站乱飞，帖子与 ticket 双向关联保证上下文不断裂，回跳入口则保证用户和客服都能回到正确处理面。
DISCUSSION
评论区