PMIVerse Federation: product goals

Purpose

Connect independent Odoo databases through stable identities and explicit authorization. People should be able to participate in several companies and instances without sharing every permission or duplicating their global identity.

The central instance is the identity and routing directory. Participating instances retain ownership of their users, credentials, accounting, application permissions, and other business records.

Identity and access

A person, legal entity, and instance each have a permanent UUID. Local user, contact, and company records have verified links to these identities. Email addresses and numeric database IDs are not proof of identity.

Access is limited to explicitly assigned instances and organizations. Membership approval uses normal Odoo administrator or delegated-manager authority. Backend and portal accounts are both supported. A membership in one company does not imply access to another.

Remote-origin accounts can receive limited central portal accounts. Elevated central access requires a separate grant. Master-origin users are provisioned only on assigned instances after their memberships are approved.

Central name/email values remain independent of each remote profile. Remote fields synchronize with revisions and conflict handling; passwords and local grants are never copied.

Authentication and account lifecycle

Shared login uses explicitly trusted Odoo Hub/Providers alongside independent local passwords. A receiver verifies each provider subject against an existing native account; authentication checks current approved membership and receiver-owned access policy. Login/logout remain instance-local, including when a user has several provider identities.

Account lifecycle distinguishes organization-role removal, instance suspension, local account disablement, and global identity suspension. Removing one grant must preserve unrelated memberships and locally owned roles.

Credential resets belong to the relevant credential owner. Federation must not store password hashes, reset tokens, or session secrets in directory or delivery records. Offline receivers need a visible enforcement deadline for revocations.

Company administration

Administrators appoint managers for exact organization/instance targets. Managers approve or suspend existing memberships and edit remote profiles within those targets. Identity verification and service configuration remain administrator-owned.

Future administrative operations must be target-specific and allowlisted. Neither shared identity nor manager status grants unrestricted remote model, database, or host access.

Encrypted company communication

Matrix provides chat, independent of federation business-operation delivery. The target is one verified Matrix account per person, master shared login plus an independent chat password, and encrypted private company rooms by default.

Users hold their own recovery keys. Odoo stores only acknowledgment metadata for a reminder, never recovery keys or the entered acknowledgment text. Company-room membership does not bypass Odoo document permissions.

Native Arch Linux services and NGINX form the intended hosting architecture. The identity domain is pmiverse.com; the homeserver endpoint is matrix.pmiverse.com. External Matrix federation is part of the target. The Element hostname and navigation model remain design choices.

Receiver-owned invoice exchange

A posted seller invoice should create exactly one draft vendor bill in the explicitly routed receiving company. The receiver resolves its own supplier, journal, accounts, taxes, fiscal position, currencies, units, and date policy.

Document identity is distinct from operation identity. Source references, dates, line facts, totals, and attachment provenance are retained. Missing mappings, duplicate candidates, and unexplained totals become review work.

Credit notes, cancellations, and corrections require explicit lifecycle handling. Receiver-edited or posted documents must not be silently overwritten. Imported counterparts must not generate reciprocal invoices.

Boundaries

The product is not general database replication, accounting consolidation, automatic posting/payment/reconciliation, or cross-database stock synchronization. Odoo modules do not install or remove external services as an installation side effect, and Matrix outages must not block accounting or local Odoo activity.

Current implementation and next work

Identity directories, scoped transport, account registration, assigned remote creation, profile synchronization, and manager delegation are implemented.

Opt-in full-suspension disablement, scoped capability discovery, and receipt reconciliation, receiver-owned role updates, and selective organization removal are implemented, together with read-only current receiver-state comparison and visible divergence. Verified correspondence also links existing users whose independently created person UUID differs from the assigned peer identity, without rewriting either identity. Multi-provider shared login, assignment repair, and receiver-approved account restoration are implemented. The initial Matrix source integration is implemented, with native host deployment configured separately. Invoice exchange remains to be implemented. See shared-login setup and contracts. The repository overview describes current addons; TODO.md is the single list of unfinished code increments.