PMIS Federation Core
The identity foundation for PMIVerse Federation on Odoo 18 Community. Core records who people and organizations are, their verified local links, and which memberships have been approved.
Features
Permanent UUIDs for people, organizations, instances, mappings, and memberships.
Verified links to local users, individual contacts, company contacts, and operating companies.
Paired verification keeps users/operating companies consistent with their native contacts.
One shared peer-identity registry for people, organizations, and selected addresses.
Stable invoice/delivery address identities with receiver-owned company scope.
Instances with operating organizations, HTTPS endpoints, and environments.
Pending Approval, Approved, and Suspended memberships.
Archive-only directory history and immutable verification information.
Reviewed identity retirement, same-directory merges, and unbound mapping correction with permanent lineage and conflict rejection.
Directory ownership
Every record belongs to a local Directory Owner company, distinct from the legal entity represented by an organization. Creating an organization does not create an Odoo company. Related directory records must share their owner.
A membership connects one person, organization, and instance. The organization must operate on that instance. Approval requires active identities and instances. Suspension changes that membership without changing unrelated memberships.
Verified mappings connect a person to a user or individual contact, or an organization to a company contact or operating company. Each local target has one mapping of its kind. Verification retains the acting user, timestamp, and a safe reference. Email similarity is not proof of ownership.
An operating-company mapping may target another enabled local company. Enable both the Directory Owner and target company while verifying the link. The organization and mapping retain their original directory owner; a local company cannot be claimed by another mapping. User mappings still require access to the Directory Owner.
Verified contacts and addresses
Verifying a user or operating company also verifies its native contact with the same identity and review reference. Conflicting links require explicit correction. Changing a verified contact into an address-only record, changing its company scope, or replacing a mapped user's/company's native contact cannot silently change ownership. Account registration can reuse an independently verified person contact.
Use Federation > Peer Identities to verify a peer UUID against a local person, organization, or address for the exact sending/receiving instances. People need no user account to participate. Archival blocks new use; reviewed correction creates a successor while preserving original evidence. Verification grants no account, company, or business access. Account retains its separate access approval checks.
Use Federation > Verified Addresses only for locations participating in federation. Verify one person/organization owner and its native contact relationship, then select invoice, delivery, or other usage. A primary contact can also represent its address; one location may serve several purposes without creating duplicate contacts. Operating Scope optionally restricts a location to one enabled local company. Native contact visibility and company-specific address restrictions still apply.
Native address detail edits keep the address UUID. Reviewed ownership/purpose changes create a new identity and preserve lineage. Document adapters can retain portable address snapshots; changing current details does not rewrite an existing snapshot. Administrators can inspect verified links through the Federation tab on native contacts, users, and companies.
Access
Depends on base. System administrators manage the directory through Federation, restricted to their allowed local companies. Ordinary internal, portal, public, and transport-service users have no direct directory access from Core.
pmis_federation_admin adds delegated manager access. pmis_federation_hub uses approval to queue previously assigned remote accounts. Core by itself neither provisions accounts nor sends traffic.
Core archival preserves directory history. Remote access lifecycle belongs to its adapters: Hub and Account support explicit or opted-in full-suspension disablement, which revokes receiver sessions and API keys only on confirmed delivery.
Current boundaries
Original identity/mapping targets remain immutable. Reviewed mapping correction creates a successor; bound access ownership uses assignment replacement.
Directory archival does not itself remove remote organization or Matrix access.
Use Federation > Review Identity Ownership and Identity Review History. See identity review, retention, and leases for verification, conflicting ownership, retirement, and native-access boundaries.
See the repository-wide development backlog and repository overview.
Localization
English source strings and a Slovenian catalog (i18n/sl.po) are included.
Bug Tracker
Bugs are tracked on PMISuite Repository Issues.
Credits
Contributors
Matjaž Mozetič
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).





