PMIS Federation Messaging

Features

Mixed Account/Hub databases verify A/B and B/C/D contacts independently in each direction. Messages and native call invitations are never implicitly forwarded. Blocking one upstream contact preserves independently approved downstream delivery and calls; each call admission and guest withdrawal belongs to its exact recipient relationship. See mixed-role ownership.

• Explicitly verified sender and recipient person/account identities.

• Exact destination instance and organization scope for each contact.

• Independent incoming and outgoing participant verification on both peers.

• Permanent route bindings and administrator verification evidence.

• Plain text limited to 4096 UTF-8 bytes.

• Immutable local preparation with author-only access in enabled companies.

• Current identity, account, company, and delegation checks before use.

• Durable outgoing operations, transactional incoming history and receipts.

• Bounded retries and duplicate protection after lost acknowledgments.

• Permanent conversation participant bindings and exact reverse reply routing.

• Participant-only local history with queued, delivered, and review status.

• Conversation inboxes, local unseen counts, and body-free notifications.

• Explicit receiver acceptance, contact blocking, and bounded size/rate policies.

• Replay-safe retention across local history, prepared snapshots, and delivery copies.

• Chat-delivered native voice/video call invitations with browser-bound guest admission.

Configuration

Install this addon on both peers.

An administrator verifies each native user's existing Core user mapping and configures separate messaging.send connections with exact organization scope. For each allowed participant pair, create an outgoing route on the sender and an incoming route on the receiver. Verify the peer's permanent person UUID and user mapping UUID explicitly; email or name matches cannot establish a route. The mapping UUID is the messaging account address, distinct from provisioning assignment UUIDs and native Odoo user IDs. Existing users and instances are reused. Configure and verify the reverse outgoing/incoming pair separately to allow replies. Incoming contacts start unaccepted. The receiver chooses Accept Contact, or an administrator explicitly sets Contact Accepted. Block Contact stops new deliveries and retries for that relationship. Default limits are 4096 UTF-8 bytes and 60 accepted new messages per hour per incoming contact; administrators can lower the byte limit or set a rate between 1 and 1000. Replays do not consume another slot. Configure Transport's external runtime bindings, HTTPS endpoints, and dedicated service credentials on each database. Enable its inactive-by-default delivery schedule only after the exact connections are authorized.

Each route is bound permanently to its connection direction, original peer pair, organization, and local user mapping. Verification does not grant business-record, company, shared-login, or native Discuss access. Administrators may archive a route or explicitly restore the same verification while its ownership remains eligible.

Usage

Internal users prepare messages through their verified contacts:

1. Open Federation Messages > Verified Contacts.

2. Select the exact verified recipient account and destination database.

3. Choose Prepare Message and enter plain text, up to 4096 UTF-8 bytes.

4. Confirm Prepare Message to save the immutable local snapshot.

5. Open Federation Messages > Prepared Messages to review prepared text.

6. Choose Send Message to queue the exact snapshot for scheduled delivery.

7. Open Federation Messages > Messages to inspect your incoming and outgoing text.

8. Choose Reply, prepare the reply, and send it through the verified reverse contact.

Conversations organizes each local participant's history. Mark Seen clears local notifications only; no remote read receipt is sent. Notifications contain no message body. Verified Contacts also shows the participant's own incoming contacts for acceptance and blocking, without opening the federation directory.

Choose Host Call in a conversation or on an outgoing contact to create a private native Discuss room and queue an invitation through chat. The recipient opens the incoming message, chooses Join Call, authenticates locally if needed, then confirms Join Call. The host and guest use the native camera/microphone controls in the same room. The guest receives access only to that room, without a full host account or an automatic host login. Hosted Calls > End Call revokes admission and removes guest membership and media sessions. Invitations expire after 30 minutes; admission tickets last at most 60 seconds and are single-use, bound to the initiating browser. Forwarding the native room URL or a ticket alone cannot enroll another browser. Both directions need independently accepted incoming contacts and configured HTTPS runtime connections. Admission fails closed when either peer is unavailable or blocked. Use a browser without an authenticated host session for guest admission; an existing host session is preserved and is never silently replaced or logged out.

The host requires working HTTPS, the native Discuss websocket proxy, browser media permissions, and reachable ICE servers. Configure native mail.ice.server STUN/TURN entries on the host, including authenticated TURN and its relay port range when NAT or firewall policy prevents direct media. Native media goes through WebRTC or TURN, never through the asynchronous federation queue. See the messaging contract for details.

Prepared Messages shows only the author's local snapshots in enabled companies. Prepared snapshots cannot be edited. Their author may delete them only before queueing. Repeating Send does not create another operation or history copy. Queued includes offline delivery; automatic retries stop after eight attempts. Needs Review requires administrator investigation through Transport, with an explicit retry after correcting the original scope or configuration. Delivered confirms acceptance by the receiving database, never read status.

Both peers require current verified participants and organization authority. Dedicated service authentication alone cannot represent an arbitrary human sender. Archived identities, disabled users, removed company access, changed connection peers, and withdrawn route scope require local review before further use. The same checks apply to queueing, each dispatch attempt, and receiver acceptance. Receiving text does not authorize a reply without a separately reviewed outgoing route.

History and conversation bindings are immutable and participant-only. Message text is plaintext in the databases, including prepared snapshots, outgoing operations, and local history; HTTPS protects transport, not secrecy from database administrators. The daily retention schedule uses pmis_federation_transport.retention_days (90 days by default, 1–3650 allowed). It removes aged incoming bodies and old unsent preparation. Settled outgoing bodies are removed together from history, preparation, and Transport after the settlement retention period. Unresolved deliveries preserve their snapshots for recovery. Permanent identities and receipt digests prevent redelivery from recreating purged messages. Retention is local and promises no remote erasure. Retiring an account prevents new delivery while its tombstones and receipts remain.

See the messaging contract for account addresses, reply routing, privacy, and native Discuss reuse.

Access and dependencies

Depends on pmis_federation_transport and native mail (Discuss). Account, Hub, shared login, and Matrix remain independent of this addon.

Company-scoped administrators verify and archive participant routes. Internal users can read their own incoming/outgoing contacts and prepare messages as themselves; administrator visibility does not authorize impersonating another participant. Public, portal, and federation service users cannot prepare messages or retrieve contacts.

Development

See the repository-wide development backlog.

Localization

English source strings and a Slovenian catalog (i18n/sl.po) are included.

Bug Tracker

Bugs are tracked on PMISuite Repository Issues.

Credits

Maintainers

Current maintainer:

Luxim is an independent R&D and deployment company focused on solving complex problems in the Odoo ecosystem.

Luxim is an active member of OCA (Odoo Community Association).