@rezti/dsh-rez-comms

Understanding draft (F.FIVE → Kelvin), updated after your review. Requirements: docs/客户通讯需求.md

A sub-package of @rezti/dsh-rez-suite — like odoo / sso / vision / wechat / tapd / gsc. Users only install the suite; we add this package to the suite's dependencies and bump its version. Nobody adds it on its own.

dsh plugin --profile web add @rezti/dsh-rez-suite@<next version>

Read thread → analyse → draft → preview → send after a person confirms. All through @rezti/dsh-rez-odoo; no new MCP host. We write no Meta client of our own.

1. WhatsApp

| Point | Detail | |---|---| | Gateway | OCA mail_gateway_whatsapp, not the paid official module (…001241) | | Phase 1 really sends and receives | Real messages both ways, not dry-run only | | Sending is manual | You press "send" in Odoo. Never automatic | | Dry-run | A check before sending. Not the delivery endpoint | | Production install is in phase 1 | Production Odoo installs the module and holds the credentials, in its own window | | Company | 浙江雷泽 company_id=1, Business number exists, every call carries company_id | | Meta rules | Outside the 24-hour session window, only template messages | | Chatter | Messages stay visible in partner chatter; no separate store |

Email inbox is not in phase 1 (…001163 separate).

Three documents, written up from step 1 (PR-C …001238):

| Document | What it answers | |---|---| | docs/comms/whatsapp-module-comparison.md | Which module, what was compared, what the chosen one costs | | docs/comms/odoo-whatsapp-mapping.md | OCA models to our Thread, and why partnerId is optional | | docs/comms/whatsapp-enablement.md | The install window checklist, in order, for your production |

comms_whatsapp_dryrun shows which side of the 24-hour window a thread is on and what would block a reply. It sends nothing, and no send tool is registered: executeSend exists with both gates and refuses on all three paths, so enabling it later is one line rather than a rewrite.

Getting there — your process, your Odoo 18.0 (18.0-20250428):

| Step | Where | What | |---|---|---| | 1 | Our own Odoo 18 | Install and check the module, get send/receive working on a test number, send you steps + screenshots. We touch none of your machines | | 2 | Your staging | ~1 day joint testing, test number, customer data removed | | 3 | Your production | You install it, we give the checklist and guide remotely. Backup first |

Credentials stay in your key mechanism, never in plain text.

2. Where data lives

| Use | Odoo | |---|---| | Customer | res.partner | | Thread | mail.message / chatter | | Outbound email | message_post or mail.mail | | WhatsApp | models added by mail_gateway_whatsapp | | Send to customer | Odoo quotations, sale.order, and ir.attachment — product images, manual PDFs, spec PDFs — can be attached directly. Not limited to Nextcloud URIs. Same for WhatsApp and email |

3. Analysis and drafting

AI drafts first → person reviews and edits → send after confirmation.

The AI reads the knowledge base (Dify publish KB / product PCP) and produces, as a starting point for a person: intent (enquiry / after-sales / logistics), key points, a suggested reply, and risk flags needing a human (price change, delivery promise, legal).

Price, delivery and discount quote only what Odoo already holds. The model never invents a number.

4. Never

Send automatically · bulk marketing or broadcast lists · use personal/work WeChat as a customer channel · install Odoo modules or change tables ourselves · change the Harness core.

Keys

Names only, values never in Git.

| Name | Use | |---|---| | REZ_ODOO_TOKEN | Odoo MCP through dsh-rez-odoo. Every thread read and every send goes through it | | REZ_COMMS_COMPANY_ID | The Odoo company every call is scoped to. Production 浙江雷泽 is 1; set a test company's id here during development | | REZ_COMMS_WA_PHONE_ID | WhatsApp Business phone number id, once the gateway is installed | | REZ_COMMS_WA_TOKEN | WhatsApp access token |

Pointing at a test company

Nothing in this package is hardcoded to a company. Every Odoo call carries an explicit company_id, taken from configuration rather than a default in the code.

Three stages, from safest to least:

Fixture only. With no Odoo connection configured, the tools read two sanitized demo threads: fixtures/thread-sample.json, a fabricated German customer on a .example address, and fixtures/thread-whatsapp-sample.json, a WhatsApp conversation from an unmapped number. The second one carries no partnerId on purpose, because a sender with no res.partner.gateway.channel row never reaches partner chatter and a fixture that hid that would hide the thing most likely to go wrong. No Odoo, no credentials, no customer data. This is how the read and analyse tools are exercised today, and it is what "不读写生产客户" means in practice: there is nothing to read from.

A test company on a staging Odoo. Point REZ_ODOO_TOKEN at the staging instance and set REZ_COMMS_COMPANY_ID to the test company. Thread reads are then scoped to that company, and a thread belonging to another company is not returned.

Production. Only after the client nominates a test partner and confirms sending is permitted. Sending always requires a person to confirm, per §8 of the requirement.