Odoo 企业版签署为什么能从 WhatsApp 一路回到已签文件：Sign、WhatsApp 与附件回流链路讲透

把签署请求发到 WhatsApp，看似只是多一个通知渠道；但 Odoo 企业版真正打通的是 whatsapp_sign、sign 与 documents_sign 三段链：请求发送、状态事件回调、以及完成文件回流归档。

## 1. 发送渠道切到 WhatsApp 后，签署请求对象本身就会改行为

在 enterprise/whatsapp_sign/models/sign_request.py，send_channel 增加了 whatsapp 选项，并在创建前校验所需模板是否都已配置。也就是说，Sign 不是“先生成请求、再想办法通知”，而是从 request 对象层就知道自己要走 WhatsApp 渠道。

2. 真正发送给签署人的不是裸链接，而是带访问上下文的 sign.request.item

enterprise/whatsapp_sign/models/sign_request_item.py 会为每个 signer 计算 document_link、attachments_download_link 和受 sudo 保护的模板变量字段。这样 WhatsApp 模板里拿到的不是手写 URL，而是与具体 signer、request access token 绑定的安全链接。

3. 完成或拒签后，消息事件继续驱动归档对象

_send_completed_documents_message() 和 _send_refused_message() 在 WhatsApp 渠道下会切换到 whatsapp.composer。同时 enterprise/documents_sign/models/sign_request.py 会在创建/完成时把 sign request 与 document folder、tag、reference_doc 绑定，并在 _sign() 后给 signer 与 requester 补 completed document 的 view access。于是消息状态和文件归档没有断层。

4. 这条链的企业价值，在于消息、签署和文档引用是同一条主线

很多实现只做到“WhatsApp 发个签署链接”，但做不到完成后文档自动回仓、权限自动补齐。Odoo 企业版这里的重点，是消息通知不会脱离 Sign request item，而 Sign request item 完成后又能回到 Documents 的 folder/tag/partner access 体系。

## 结论

所以，Odoo 企业版 Sign 走 WhatsApp 时，真正串起来的是 channel、request item 安全链接以及 completed document 归档，而不是单纯多发一条即时消息。

主要源码锚点：

- `enterprise/whatsapp_sign/models/sign_request.py`

• enterprise/whatsapp_sign/models/sign_request_item.py
• enterprise/documents_sign/models/sign_request.py
• enterprise/documents_sign/models/sign_template.py