PMIS Federation Hub

Features

• One remote account per source instance/account UUID.

• Opt-in limited master portal registration from authenticated observations.

• Explicit verification of existing identity matches.

• Independent master, desired remote, and last-observed profile values.

• Revision-aware updates, visible conflicts, and delivery status.

• Approved master-origin provisioning on explicitly assigned instances.

• Opt-in account disable requests after every assigned membership is suspended.

• Selective organization withdrawal with immutable delivery and receiver confirmation.

• A read-only own-account portal at /my/federation.

Organization withdrawal

Suspending an assigned membership records Organization Removals Requested. One matching outgoing membership.remove connection queues the withdrawal; missing or ambiguous configuration preserves suspension and visible intent. Queue Organization Removal queues requests after configuration is corrected. Uncertain requests retain their original identity and receipt. Confirmed rejection allows a new operation after receiver policy is repaired. Administrators can use Reconcile Receipt on the outgoing operation after a lost response.

Organization Removals Confirmed records enforcement evidence, including a receiver withdrawal recorded before uncertain account creation. Only that organization's managed profiles and company grants are removed; independent local company access and a valid receiver default company survive. Other approved organizations retain their grants and can request receiver roles. Reapproval cannot restore withdrawn access. Unconfirmed assignments can explicitly drop withdrawn scope through verified repair. Existing assignments require receiver-approved replacement; confirmed disablement requires explicit receiver and Hub restoration review.

Remote-origin registration

Allow Limited Portal Registration is disabled by default on remote instances. When enabled for an authenticated peer, a new remote identity without existing identity/login/email matches creates a portal-only master user and verified mapping.

Matches, including inactive ones, remain in Link Review. Verify Existing Account links an eligible master user after administrator verification. Email similarity and claimed UUIDs do not authorize automatic linking.

Registration initializes master name/email once; later observations do not overwrite it. No password, invitation, internal role, or administrator role is copied. Missing memberships are created pending approval; existing membership decisions are preserved.

Master-origin assignment

The same database can run Account and Hub, optionally with Login and Provider. One native user and verified person mapping can participate under an upstream Hub and own independently reviewed downstream assignments. Upstream trust, approvals, profile changes, and revocations do not automatically extend downstream. Release any exclusive receiver access lease before assigning or linking that user as a downstream master. Non-retired downstream ownership, including archived assignments, prevents upstream whole-account disablement and exclusive leases. See mixed-role setup and ownership.

Federation > Assign Remote Account records the master user, provisioning connection, organizations, and verification reference. All assigned memberships must be approved before creation is queued. Already approved assignments queue immediately.

The receiver chooses internal/portal type and initial local roles. The same person/account UUIDs are confirmed across peers. When the receiver links an existing user, the first authenticated observation establishes that user's retained profile independently of receipt arrival order. Queue Account Creation recovers existing work or a durable rejection without duplicating uncertain deliveries. Reviewed uncertain requests resume with the original UUID, payload, and attempt count after current approvals and account scope are rechecked. Pending requests retain their existing retry schedule.

Administrators can use Reconcile Account Creation after suspension or a lost acknowledgment. It retrieves the exact original receipt without replaying creation or approving memberships. A successful receipt confirms the account, then applies the existing opt-in full-suspension disable policy. With the default policy, the administrator can queue disablement separately. Missing receipts remain unconfirmed; changed identities or delegations require explicit repair.

Known master-origin accounts can report observations without enabling unsolicited portal registration. See provisioning.

Repairing unconfirmed assignments

Administrators use Repair Unconfirmed Assignment to replace a provisioning connection or organization set after explicit verification. The master user, person UUID, remote account UUID, receiving instance, directory owner, and original sending instance remain unchanged. Never-queued assignments are eligible; every earlier creation otherwise requires a durable receiver rejection. Pending, uncertain, and successful deliveries block repair, including work on older connections.

Withdrawn organizations cannot be restored through repair. A reduced assignment retains original removal requests, confirmations, and membership decisions. New organizations receive pending memberships. Assignment Repair History records the administrator, verification time/reference, and previous/repaired scope without profile or credential values. Existing operations retain their UUIDs, envelopes, digests, receipts, and attempt counts. Rejected operations are retired in place; later creation uses a new operation. Stale open reviews cannot overwrite newer repair.

Repair returns to Awaiting Membership Approval without approving memberships or queuing creation. Approve the reviewed memberships and use Queue Account Creation separately. Identity correction and existing accounts use the replacement workflow below.

Replacing reviewed assignments

Replace Reviewed Assignment handles corrected master identity, already registered accounts, changed confirmed delegation, and renewed withdrawn scope. Resolve every original operation first: pending or unknown effects block replacement. The receiver administrator verifies the exact eligible native user and creates an immutable assignment.repair approval with a fresh assignment UUID and current-state snapshot. The Hub administrator copies those UUIDs, reviews the verified master user and exact scope, and explicitly chooses whether to approve reviewed replacement memberships.

The original assignment is archived, never retargeted, and its operations, receipts, withdrawals, and membership history remain traceable. The successor stays Assignment Repair Pending until the receiver's actual profile is observed. Confirmation of the repair receipt does not overwrite profiles. Receiver edits require fresh approval; durably rejected proposals retain their evidence when replaced. Old UUIDs cannot authorize delayed mutations or reactivate retired assignments. Repair preserves the receiver's permanent mapping, credentials, native profile, and independent access. Excluded scope loses only managed grants; new scope grants no roles automatically. For confirmed federation disablement, the receiver creates an approval explicitly selecting Restore Disabled Account. The Hub administrator selects the same option in Replace Reviewed Assignment, copies that approval's fresh UUIDs, and explicitly approves the reviewed replacement memberships when needed. A pending or unknown disable outcome must be reconciled first. The original disabled assignment remains archived with its confirmations; Restoration Requested records intent on the successor. Repair Confirmed and the receiver's actual profile remain separate evidence. Ordinary membership reapproval cannot reactivate the original account. The receiver rotates credentials, sessions, keys, and native recovery links and sends a fresh local reset email. Lost responses reconcile the same durable repair receipt; rejected restoration proposals need a fresh receiver approval and successor request. See provisioning.

Profile ownership and state

Master Name and Master Email display the central user's own values. Remote Name and Remote Email hold desired remote values; observed fields retain the last reported values and revision.

Editing a current profile advances its desired revision and sets Update Pending. With one eligible outgoing profile.apply connection, the edit and queue creation are atomic. Approved memberships and active verified links are required for every assigned organization.

Without a matching connection, values remain pending. Queue Pending Update can queue them later without replacing an operation or resetting retries. Validated delivery or a matching observation returns the account to Current.

Conflicting newer observations preserve desired values in Update Conflict. Accept Remote Values accepts the observation. Discard Rejected Update restores observed values only for never-queued work or confirmed rejection; uncertain or successful delivery cannot be discarded that way.

Receiver role updates

Administrators use Request Receiver Roles on an observed, verified remote account. Configure a separate outgoing roles.apply connection to the same peers and Directory Owner. Every assigned membership must remain approved. Supply one organization, the receiver-approved profile key and policy revision, and the receiver's current account Role Revision (initially zero). The receiver chooses native roles; no group identifiers are sent.

The request advances the receiver's role revision once without changing name/email revisions. Empty receiver policies withdraw only the selected profile's managed grants. A changed policy or stale revision receives a durable rejection. After correcting a confirmed rejection, an administrator can queue a new request; the rejected operation remains intact. Pending and uncertain role requests block new requests until the original delivery is retried or reconciled through Delivery > Outgoing Operations > Reconcile Receipt. Receipt lookup never reapplies roles. Changed memberships or delegation block dispatch and reconciliation.

Access and dependencies

Depends on pmis_federation_transport, portal, and auth_signup. Company-scoped administrators manage accounts and verify links. pmis_federation_admin adds exact organization/instance manager delegation.

Incoming profile.observe receives profiles; outgoing profile.apply and membership.provision serve updates and creation. All require transport authentication, organization delegation, and runtime binding.

The Company Instances portal displays only the current user's verified linked accounts, with 50 accounts per page. Ordinary portal users cannot edit profiles or retrieve unrelated accounts.

Development

See the repository-wide development backlog.

Account disablement

Suspend every assigned membership, then use Queue Account Disable on the remote account. This administrator-only action requires confirmed provisioning. Alternatively, an administrator can enable Disable Accounts After Full Suspension on the target instance. The suspension action then requests disablement when every assigned membership is suspended, including suspensions by an exact delegated manager. The policy is disabled by default. It applies only to confirmed federation-created accounts and includes archived central profiles. Other instances and independently registered accounts keep their separate access decisions.

Configure a separate outgoing account.disable connection to the same peers and complete organization set. Repeated requests preserve uncertain deliveries; confirmed rejections can be replaced after correcting receiver configuration.

Disable Requested and Remote Disabled distinguish intent from confirmation. Missing or ambiguous connections leave an unconfirmed request that can be queued again after configuration. Unconfirmed Revocations filters these accounts. Automatic requests preserve suspension and visible intent when connection configuration is unavailable or invalid. Repeating suspension preserves existing delivery history and does not automatically retry receiver rejections. To apply a newly enabled policy to already suspended memberships, repeat the suspension action or use Queue Account Disable. Reapproval is blocked once requested because a receiver may already have disabled the account. Central accounts and other instances remain active. This workflow does not remove individual organization grants, restore accounts, or repair changed delegation.

Administrators can retrieve lost disablement or profile acknowledgments through Delivery > Outgoing Operations > Reconcile Receipt without resending the request. The exact current target scope is rechecked. A missing receipt leaves enforcement unconfirmed; a historical disablement receipt cannot detect later local reactivation.

Revocation review deadlines

Each target instance has Revocation Review Deadline (Hours), administrator-owned and defaulting to 24 hours. Zero disables the deadline for new requests; the maximum is 8760 hours. A request records its first timestamp and snapshots this deadline, including when the connection is missing or automatic queueing fails. Retries, repeated suspension, and policy changes do not extend existing deadlines.

Overdue Revocations filters expired unconfirmed requests within the current directory-owner company scope. The list highlights these accounts in red; refresh it to update time-dependent status. A matching successful receipt records Disable Confirmation Received At and removes the overdue status. This timestamp records receipt confirmation at the hub, not the time of the receiver's original effect.

The deadline is an operational review target. It does not disable an offline receiver, guarantee enforcement, or authorize account restoration.

Current-state reconciliation

Configure one outgoing account.inspect connection covering the account's peer and all assigned organizations, with a separate incoming inspection connection on the receiver. Administrators use Inspect Receiver State on a verified, confirmed account, including after suspension or disablement. Last Receiver Inspection and its timestamp distinguish matching state, Receiver Divergence, and unavailable inspection; the list has a divergence filter. Checks compare current native receiver state with desired profiles, acknowledged revisions, withdrawals, and disablement intent. Inspection preserves delivery history and local authority. A matched snapshot is not continuous enforcement; failed or mismatched queries cannot prove current access. Receiver-approved assignment replacement and explicit disabled-account restoration are separate from inspection.

Supporting recovery

Core supplies reviewed identity retirement and unbound mapping correction. Bound Hub account ownership uses reviewed assignment replacement. Transport compacts only settled profile text while retaining assignment and replay evidence. Account can enforce optional receiver leases on eligible provisioned users; Hub review deadlines remain monitoring targets and do not renew those leases. See identity review, retention, and leases.

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).