很多人把电话集成 Helpdesk 理解成“响铃时弹一张工单”。但 /home/ubuntu/odoo-temp/enterprise/voip_helpdesk 真正做的是一层很轻、却很关键的上下文桥接：电话对象不自己维护客服事实，而是复用 partner 的 Helpdesk 语义。
参考入口：
enterprise/voip_helpdesk/models/voip_call.pyenterprise/voip_helpdesk/models/res_partner.pyenterprise/voip_helpdesk/tests/test_voip_call.py
一、来电上的工单计数，本质上是 partner 视角的投影
voip.call 上的 ticket_count 与 open_ticket_count 都是 related 字段，直接指向 partner_id.ticket_count 与 partner_id.open_ticket_count，并且设置了 related_sudo=False。
这意味着来电弹窗不是自己重算工单，而是借用联系人已有的客服上下文；同时它不会偷偷 sudo 越权，把用户看不到的工单数字硬显示出来。
二、为什么 open_ticket_count 单独算
res.partner 上新增了 ticket_ids 和 _compute_open_ticket_count()，逻辑很简单：fold=False 的 stage 才算 open。简单归简单，但业务含义明确：客服接电话时最重要的不是客户一生建过几张单，而是当前还有几张没关。
三、入口不是永远新建单，而是先看有没有上下文可复用
voip_action_open_helpdesk_ticket() 只有在 ticket_count == 0 时才打开 Helpdesk 新建表单；否则直接走 partner_id.action_open_helpdesk_ticket()。
这体现了企业现场一个很务实的优先级：先承接已有问题，再决定要不要开新 case。否则同一位客户重复来电，很容易被拆出多张孤立工单。
四、新建单默认值里为什么带 partner_phone 和 partner_id
在没有既有工单时，动作会传入：
default_partner_phone = self.phone_numberdefault_partner_id = self.partner_id.id
这看似只是省手工录入，实际上是在把电话事实可靠地落到 Helpdesk 入口。很多团队只传联系人，不传本次号码，后面就很难判断这次来电是主号码、分机还是临时回拨号码。
五、测试说明了什么
test_voip_call_ticket_count_user 与 test_voip_call_ticket_count_manager 都验证：call 上看到的计数应与 partner 一致。也就是说，官方刻意避免“电话对象一套数、联系人对象另一套数”的双重真相。
六、实战注意事项
- 如果来电页计数不对，先查 partner 工单权限，再查 related_sudo 行为，不要先怀疑电话模块。
- 想减少重复建单时，重点优化
partner_id识别准确率，因为入口分流完全依赖它。 - 不要把“来电即新 case”当默认流程，已有 open ticket 才是更优先的客服上下文。
七、结论
voip_helpdesk 的价值不在于多一个按钮，而在于让电话场景自动站到正确的客服上下文里：看同一个联系人、继承同一套工单计数、优先打开已有问题、必要时再创建新单。
DISCUSSION
评论区