PMIVerse Federation
Connect Odoo databases. Keep each one in control.
PMIVerse Federation connects independent Odoo 18 Community databases through verified identities, approved account access, and explicitly trusted login providers. Work across organizations and instances without turning them into one shared database.
Shared identity. Local authority. Independent business data.
Explore the capabilities · Start here · See what is next · Read the architecture
Project status: Alpha. Account federation and multi-provider shared login are implemented, together with bidirectional order exchange, direct messages, receiver controls, retention, and native call invitations. Matrix integrates directly with an existing Synapse service over HTTPS, with company settings and restricted credentials. Matrix server deployment and backups are outside Odoo. Invoice exchange is planned. The addons target fresh installations and have no production deployments yet.
Verified messaging contacts support conversation inboxes, local notifications, receiver acceptance and blocking, replay-safe retention, and chat invitations to native Discuss calls with restricted guest admission.
Why federation?
A company, partner, or team can run its own Odoo database and still participate in a wider network. People may need accounts in several instances, but that does not mean their passwords, permissions, or business records should become shared.
Federation separates those concerns:
- Recognize the person: explicitly verify how a federation identity relates to each local account, including existing accounts with different person UUIDs.
- Approve the access: authorize organization and instance memberships separately from identity verification and authentication.
- Keep decisions local: each receiver controls its companies, roles, credentials, and business records.
- Choose whom to trust: a receiver may trust several Odoo Hub/Providers. Trusting one provider does not automatically trust the rest of its network.
This is not database replication, unrestricted remote administration, accounting consolidation, or automatic access for everyone with a shared identity.
What you can do today
Log in across instances—without sharing passwords
Choose a trusted Odoo provider on a receiving database's login page. Authenticate with that provider's native credentials and configured MFA, then return to an already verified local account. One local user can have several independently verified provider identities.
Local-password login remains available for independently authorized accounts. Every instance has its own explicit login and logout: signing out of one does not sign out of the provider or another receiver.
Shared-login setup and security
Give people approved accounts in the right databases
Register remote accounts, review identity matches, and assign users to selected instances after membership approval. Receivers can create internal or portal accounts, or explicitly link eligible existing users without replacing their local credentials and profiles.
Hub administrators manage remote account profiles; delegated managers act only within their assigned organization/instance scope. Users can see their own linked accounts through the federation portal.
Account onboarding and provisioning · Delegated administration
Withdraw access without removing unrelated ownership
Managed roles and company access retain their organization/provider attribution. Withdrawing one owner's scope preserves independent local grants and surviving owners, including overlapping roles and company access.
Whole-account disablement is a separate, restricted workflow for eligible federation-created accounts—not a way for one provider to disable every identity of an independently managed local user. Corrections, assignment replacement, restoration, and local credential recovery require explicit receiver review.
Receiver access and recovery · Identity review, retention, and leases
Handle delivery failures visibly
Business operations use scoped authenticated connections, durable receipts, duplicate protection, and bounded retries. Administrators can reconcile lost acknowledgments and inspect current receiver state without blindly repeating business effects or silently repairing permissions.
Transport and operation ownership
Exchange direct text messages
Send text to an explicitly verified account in another database, then reply through an independently verified reverse contact. Offline delivery remains queued; bounded retries and immutable receipts prevent duplicate messages after lost replies. Local history is visible only to the local participant in enabled companies. Delivery confirmation does not mean that the recipient has read the message. Receivers accept or block individual verified contacts and set bounded delivery limits. Conversation inboxes track local unseen messages. Hosts can invite a remote participant to a native voice/video call without creating a host account or sharing a native invitation URL.
Organize Matrix rooms in reviewed Spaces
Provision organization-owned, invite-only Matrix Spaces and encrypted child rooms under an exact verified target and operating-company mapping. Approve each Space and room membership separately: Space participation grants no child-room access, and Space withdrawal preserves independently approved rooms and downstream scope. Company settings supply restricted credentials. Odoo calls the existing Synapse service directly over verified HTTPS and records remote ownership evidence for retries.
Matrix's Odoo interface is available in US English and Slovenian. Recovery instructions
are localized; the exact confirmation phrase remains I saved my recovery key.
Open Matrix Client or choose Open in Odoo on a personal identity or approved room membership to use the configured Element Web client within Odoo. Element handles encrypted chat, history, attachments, recovery, and its supported voice/video and web conferencing interface. A separate HTTPS client origin, explicit permission to embed in Odoo, and a working MatrixRTC deployment are required. Odoo rechecks the verified native identity and company access while the view is open; personal Matrix sessions remain owned by Element and receive no company integration credentials.
The frontend dependency is the separately installed Element Web application
(extra/element-web on Arch Linux). Its package owns client assets and updates;
the Odoo module embeds the configured HTTPS origin and ships no browser Matrix SDK,
WebAssembly, npm packages, or client build tooling.
See Element Web setup and updates.
Reviewed Matrix room membership controls access to Element chat and calls. Element and the Matrix deployment own call admission, moderation, and disconnection; Odoo does not maintain separate call approvals or invitation leases. Discuss participant withdrawal preserves independently approved Matrix room access, and room membership withdrawal does not guarantee immediate disconnection of an active SFU participant.
Reviewed Discuss bridges use dedicated matrix-nio[e2e] devices over pinned HTTPS.
Only verified encrypted text crosses the exact approved room/channel boundary,
with original sender attribution, ordered delivery, durable replay evidence, and
scoped withdrawal. Device keys and ciphertext journals stay in protected Odoo
runtime storage; readable Discuss history requires explicit receiver consent.
How it fits together
Hub maintains a directory of people, memberships, and remote account profiles. A chosen Hub can also be a Provider, authenticating its native users for explicitly registered receivers.
Each participating database uses Account for its local account adapter. Add Login where shared login is wanted and Administration where exact manager delegation is needed. Core identities and scoped Transport underpin these roles.
There is no mandatory single login provider. A receiver can independently trust multiple Hub/Providers and link their verified subjects to the same native user.
One organization, different business contexts
Core already provides permanent organization identities and verified mappings to local operating companies and organization contacts. A legal entity's identity is distinct from the role it plays: it may operate its own Odoo company and appear as a customer or supplier in other databases.
Verifying a user or operating company also verifies its native contact in the same reviewed operation. Core maintains peer correspondence for people, organizations, and explicitly selected addresses; Account adds its own eligibility and access checks. One location can serve both invoice and delivery purposes. Native address details remain local, while document-time snapshots preserve historical values.
Transport includes an account-independent v1 order contract for structured RFQs, quotations, and purchase/sales orders, with decimal commercial amounts and frozen party/address references. The Orders adapter adds explicit native Send, receiver-owned drafts, same-exchange responses, and reviewed revisions.
Exchange extends the contract library with invoice/refund, shipment/return, cancellation/replacement, and acknowledgment schemas. Its native tax and approved unit-conversion calculations preserve quoted untaxed amounts using each side's local settings. Receiver-owned route approvals bind exact instance pairs, operating companies, counterparties, capabilities, and verified sender memberships. Reviewed product-variant, unit, and packaging mappings are scoped to each route. Administrators can explicitly select or create approved native partners and product variants without matching authority by names or codes. Incoming document snapshots and append-only receipts preserve exact operation, revision, party, address, and dependency evidence. Retries reuse the original snapshot; unresolved links and changed verification remain in receiver review. Authenticated document channels now connect this journal to Transport. Durable outgoing snapshots preserve native source ownership, frozen invoice PDFs and explicitly selected supporting files, bounded retries, and exact remote receipts. Commercial adapter inputs resolve approved units and local taxes while preserving priced productless fallback. Native order serialization retains permanent company-scoped sender document, line, product, unit, and packaging references, with seller-only price authority and buyer amounts kept as evidence. Orders creates linked native drafts, preserves quotation prices and local taxes, and requires explicit receiver acceptance of revisions or local conflicts. Receiver-opted-in updates affect untouched drafts only.
The stock and accounting adapters will build on that foundation with verified seller/buyer identities, explicit company routing, and receiver-owned accounting mappings. Multi-company databases must keep each operating company's permissions and documents isolated. A shared counterparty or federation Directory Owner is not authorization to act for another company; independently created organization identities use verified correspondence, never automatic name or VAT matching.
Trust has boundaries
One database can combine Account + Hub and Login + Provider under its existing instance identity. Upstream participation and downstream account ownership reuse verified native users while keeping each peer's authority separate. Upstream withdrawal does not forward downstream revocation; independent local access and downstream ownership prevent whole-account upstream disablement. Messaging contacts and native call admission remain specific to each peer; Matrix jobs and membership withdrawal remain specific to each verified target.
Mixed-role setup and ownership
- UUIDs, names, and email matches are not proof of ownership or permission.
- Provider credentials stay with the provider; receiver permissions stay with the receiver.
- Configuration binds traffic to the original database, instance, environment, and external runtime. A copied database alone must not activate federation traffic.
- Shared authorization lasts at most five minutes; shared sessions have a thirty-minute idle limit and an eight-hour absolute limit. Provider outages fail closed at the affected session's authorization deadline.
- Queuing a remote withdrawal is not proof that it was enforced. Receipts and current-state checks expose what is confirmed and what remains uncertain.
Start here
- Choose a first use case. Start with approved account onboarding or shared login between explicitly chosen instances—not every workflow at once.
- Choose the database roles. Install Hub on the directory database and Account on participating receivers. Add Provider and Login for shared authentication; Administration is optional for delegated managers.
- Verify identities and scope. Review users, organizations, instances, and operating-company mappings. Configure exact peer capabilities and approved memberships before granting access.
- Configure the runtime. Supply protected external database bindings and credentials or signing/verification keys. Install the Python dependencies in requirements.txt alongside Odoo's requirements.
- Follow the matching setup guide. Use provisioning or shared login, together with the module READMEs below.
Installation alone does not establish trust or activate federation connections. Scheduled business delivery is inactive by default. Shared-login deployments need separate HTTPS hostnames and database routing for independent browser cookie scopes; native database selection under one shared hostname is not equivalent.
Matrix management requires its separately configured native service and host runtime binding. See the Matrix module README for its configuration prerequisites.
Modules
Install the roles you need; their manifests declare the supporting dependencies.
| Module | Responsibility | Read more |
|---|---|---|
pmis_federation_core |
Permanent identities, verified local mappings, and memberships. | Core |
pmis_federation_transport |
Scoped connections, runtime isolation, durable delivery, and shared-login primitives. | Transport |
pmis_federation_exchange |
Verified document channels, native commercial inputs, immutable journals/files, durable outgoing delivery, and receiver verification reviews. | Exchange |
pmis_federation_order |
Explicit native order Send, linked receiver drafts, exact quotation responses, and receiver-owned revision review. | Orders |
pmis_federation_account |
Receiver-owned accounts, access grants, profile application, and recovery. | Account |
pmis_federation_hub |
Account directory, reviewed registration, and assigned provisioning. | Hub |
pmis_federation_admin |
Exact organization/instance delegation and manager workflows. | Administration |
pmis_federation_provider |
Native Hub authentication and signed authorization for registered receivers. | Provider |
pmis_federation_login |
Explicit receiver trust, verified provider identities, and bounded shared login. | Login |
pmis_federation_messaging |
Verified conversations, receiver controls, retention, exact replies, and native guest call invitations. | Messaging |
pmis_federation_matrix |
Verified Matrix identities, encrypted organization rooms, private Spaces, reviewed access, native management jobs, and an embedded Element chat/conferencing client. | Matrix |
English source messages and Slovenian translations are included.
Integration scope
Matrix identity, room, Space, reviewed membership, embedded Element, and encrypted Discuss text relay integrations are implemented. Business document adapters for stock pickings and invoices/bills remain planned. Purchase/sales order exchange provides native Send, automatic verified drafts, explicit counterpart reuse, exact quotation terms, supporting files, and reviewed revision application.
Matrix server setup, production module installation, and live federation acceptance come later. Remaining code deliverables are tracked centrally in TODO.md.
Invoice exchange remains a planned adapter and will remain independent of chat; native call invitations do not imply fully federated real-time call interfaces or automatic access to another database.
TODO.md is the single implementation backlog, with scope, dependencies, and observable completion criteria. See project goals for the broader direction.
Documentation
- Architecture and ownership
- Shared-login setup and protocol
- Provisioning, access changes, and restoration
- Transport version 1
- Identity review, retention, and leases
- Matrix integration and native configuration
Project checks
Repository test and coverage badges
Issues and maintainers
Report bugs and scoped enhancement proposals through PMISuite Repository Issues. Do not include credentials, customer data, or unredacted production logs.