PMIS Federation Account

Features

• Administrator registration of existing internal users through Federation > Register Local Account.

• Optional registration of newly created internal users.

• Stable local account/person mappings and queued profile observations.

• Master-origin internal or portal creation with receiver-owned initial roles.

• Explicit assigned-account linking through receiver-verified existing user mappings.

• Verified correspondence for independently created local and peer person UUIDs.

• Organization/profile ownership of managed roles, separate from independent local grants.

• Revision-checked name/email application and duplicate protection.

• Separate ownership of managed companies and independent local company access.

• Preservation of login, passwords, independent companies, and local groups.

• Permanent organization withdrawals, including delayed account creation protection.

• Explicit receiver administrator approval of target-specific native password resets.

• Mixed Account/Hub ownership with separate upstream and downstream authority.

Mixed participant and Hub roles

Account and Hub may share one permanent local instance and verified native user. Organization withdrawals preserve independently assigned local grants and do not forward downstream revocations. Whole-account upstream disablement requires review when the user has independent local roles or non-retired downstream Hub ownership. Exclusive leases cannot coexist with that ownership: release an unexpired lease before assigning, linking, or replacing a downstream master account. See mixed-role setup and ownership.

Local credential recovery

On the receiver, select one account in Federation > Local Accounts and use Action > Send Local Password Reset. A receiver system administrator must enable the account's Directory Owner. The verified account, person, user, observation delegation, and retained operating-company mappings must still be eligible. Privileged users, disabled accounts, and users sharing a contact with another native user require local review. This action also supports verified registered or linked accounts; their independent access remains receiver-owned.

The native auth_signup workflow sends a reset link to the receiver user's current local email. Only that native workflow handles the link and new password; federation returns no link, password, or token and stores no credential copy. Configure outgoing email and the receiver's public base URL locally. Reset requests preserve existing passwords, sessions, API keys, roles, companies, and federation revisions until the user completes the native password change. A failed delivery remains an error. Requesting a reset does not reactivate a disabled account or authorize new access. No hub or service delegation can invoke this receiver administrator action.

Organization withdrawal

An incoming membership.remove connection authorizes one account/person UUID and exactly one delegated organization. The receiver withdraws all its managed profiles and original managed company grants, preserving groups owned locally or by another organization, their implied roles, independent companies, local credentials, and account activity. Registered and linked users keep their pre-existing companies. Provisioned users retain the Directory Owner as independent company access. Native company membership edits, including company-side Accepted Users, record local ownership separately; an explicit local addition of an already managed company preserves it after withdrawal. The current default company survives when valid; otherwise the receiver selects a surviving company. Removing the final company requires local review and rolls back the withdrawal.

Federation > Managed Company Grants shows active and withdrawn ownership, linked to the original verified mapping. Archiving that mapping does not erase ownership or prevent withdrawal. Local Accounts optionally shows Independent Local Companies.

Federation > Organization Withdrawals retains permanent evidence, even when the assignment has not reached the receiver yet. Delayed creation including a withdrawn organization is rejected without creating a user. Historical successful role receipts remain readable and replay without reapplying grants; new requests cannot regrant withdrawn access. Other organizations can still receive roles. Renewal or narrowed reassignment requires explicit receiver-approved replacement. Disabled-account restoration requires the explicit approval described below.

Assignment replacement

System administrators create Federation > Assignment Repair Approvals after verifying the exact local user, desired peer person UUID, new incoming assignment.repair delegation, outgoing observation connection, and organization scope. The permanent approval freezes current native and assignment state and issues a fresh replacement UUID. Share its portable request payload with the authorized Hub administrator; it contains no credentials or native record identifiers.

Applying the exact approval preserves the native user, profile, credentials, independent roles and companies, original local UUID, and permanent mapping. Only excluded organizations lose their managed grants. Independent local edits invalidate stale approval and require fresh review. Conflicting identity ownership, privileged targets, and disabled users without restoration approval are rejected. Historical UUIDs remain reserved: delayed old-target mutations cannot execute, while original receipts still replay without repeating effects. Withdrawn scope can receive new receiver-owned grants only under the explicitly approved new alias, never through ordinary reapproval. Repair queues the actual local profile under that alias and its approved peer. See provisioning for the complete two-administrator workflow and disabled-account boundaries.

Disabled-account restoration

The receiver administrator creates a new Assignment Repair Approval with Restore Disabled Account after confirming federation disablement. Only federation-provisioned users still inactive under that disablement are eligible. Local reactivation, linked/registered ownership, additional company access, shared contacts, privileged users, and inactive verification require local review.

Review the original Provisioning Connection and its New Account Type and Local Roles for New Accounts before approval. Restoration freezes that role policy together with the native account state, and renews its initial managed profile for each approved organization under the new assignment. Independent local permissions remain owned locally. Changed receiver state or role policy requires fresh approval.

After Hub membership and restoration review, the exact assignment.repair request consumes the approval once. Restoration replaces the password with an inaccessible random native credential, rotates the session revocation nonce, deletes API keys, and sends a fresh native reset link to the receiver user's local email. Earlier passwords, sessions, keys, and recovery links cannot regain access. The user sets a new local password through that link; federation stores or returns no credential copy. Email failure rolls back restoration and leaves a durable rejected receipt; fix delivery and create a fresh approval/request rather than replaying the rejection.

Previous Disabled At preserves the disablement timestamp on permanent approval evidence; Restored At records local restoration. Original disablement receipts remain readable without repeating effects. Delayed requests for any old assignment UUID are rejected, even after successful restoration.

Registration

Registration requires an active internal user, verified operating-company mappings, and an outgoing profile.observe connection covering the selected organizations. It reuses a valid person mapping or creates one with administrator verification attribution, then queues the first observation.

Register New Local Users is an opt-in connection setting. It applies only to new internal users and requires exactly one eligible connection. Existing, portal, inactive, and federation-service users are not automatically registered.

Share Verified Person Identity optionally includes the person's UUID in observations for an identity-aware hub. Existing links are not automatically rewritten or merged.

Assigned account creation

An incoming membership.provision connection receives approved master assignments. New Account Type chooses Internal User or Portal User; Local Roles for New Accounts selects receiver-owned initial roles. Creation requires one eligible reciprocal outgoing observation connection. Verified organization mappings select the local operating companies. A new user receives those companies and the Directory Owner, which remains the default company. The sender cannot supply native company IDs. Before registration or linking, existing users must already have access to the Directory Owner and a verified mapped company for each assigned organization.

The receiver creates the requested account/person UUIDs and a generated federation-<account UUID> login. Existing identity/email collisions block creation. Mixed user types and administrator, access-rights, public, and service groups are rejected, including implied groups.

Passwords and invitations are not copied from the master. Local credentials belong to the receiver. Portal application access depends on installed applications.

See provisioning.

Existing-account linking

An administrator verifies a User Account mapping to the existing receiver user with a safe verification reference. When the local identity has the shared person UUID, the mapping can be used directly. If the local person already has a different UUID, create Federation > Person Correspondence with that mapping, the verified peer UUID, and the exact sending and receiving instances. Record a safe reference to independent identity verification; email or login matches alone are insufficient. Enable Link Verified Existing Users on the incoming membership.provision connection and select the matching account type. The master can then queue its approved assignment through the normal workflow.

The receiver requires exactly one active verified mapping, an active eligible user, verified operating-company mappings, and one reciprocal observation connection. Ambiguous, archived, already registered, cross-owner, administrator, public, and service targets are rejected. Email and login matches never create identity links. Correspondence cannot override another local person's canonical UUID or permanently claim the same peer identity for another user. Its verification and targets cannot be edited or deleted. It never changes a local UUID, creates a user, grants access, or rewrites existing accounts or operations. Already registered account retargeting still requires explicit assignment repair.

Linking preserves the existing name, email, login, password, sessions, API keys, company access, and roles. Local Roles for New Accounts do not modify linked users. The initial observation publishes the receiver's profile and assigned peer person UUID. For differing identities, Verified Person Correspondence on Local Accounts retains the original binding. Profile updates, receiver roles, inspection, and organization withdrawal respect that binding. Archiving it blocks new access workflows, while historical receipts remain replayable and organization withdrawal remains possible. Archival does not disable the native user or remove independent local access. A prior rejected operation stays rejected; queue new work after reviewed verification rather than rewriting its envelope or receipt. Replays reuse the same account without duplicating users or observations. Linking Connection records assignment authority separately from Provisioning Connection; linked users remain locally owned and cannot be disabled through account.disable.

Managed grant ownership

Federation > Managed Grants lists each account, organization, receiver profile key, native group, and active/withdrawn state. Ownership is permanent evidence; ordinary model creation, editing, and deletion cannot bypass the receiver workflow. Only system administrators can read ownership, filtered by Directory Owner.

Fresh provisioning records the receiver-selected direct roles, including the account type, under the initial profile for each assigned organization. Implied permissions are derived from those roles. Provisioning retries never refresh grants from a changed connection policy. Verified registration and existing-account linking instead record the user's current groups as independent local permissions and add no managed grants.

The checked receiver method _set_profile_grants replaces one organization's profile snapshot, preserving other profiles and organizations. Native permissions are the union of surviving managed roles, independent local groups, and their implications. Withdrawal archives ownership; an explicitly authorized replacement can reuse it. Administrator, public, and federation-service grants are rejected, including implied privileges. Native user-type constraints still apply, and a failed replacement rolls back its ownership changes.

Native user-form group fields, groups_id edits, and group-side users edits update local ownership separately. An explicit local addition keeps that group after managed withdrawal, even when it was already present. Removing local ownership leaves active managed access intact; withdrawing managed access uses the receiver workflow. User group clear/set operations are explicit replacements of local ownership. Nested group creation, modification, or deletion through a registered user's membership field requires separate group administration. Existing credentials and company grants are unaffected. Role edits are serialized with native user/profile changes.

Organization-removal delivery remains unfinished. The addon targets fresh installations.

Receiver role profiles

Configure a separate incoming roles.apply connection, then use Federation > Receiver Role Profiles to define an organization, permanent profile key, and approved local roles. Only directory-owner administrators manage policies. Every role or archive edit advances Policy Revision; profiles can be archived, not deleted or retargeted. Administrative, public, and service implications are denied both when configuring policy and when applying it.

The sender supplies the verified account/person UUIDs, one organization UUID, profile key, policy revision, and expected/next account role revisions. It cannot send native groups. Account Role Revision starts at zero and advances once per successful update independently of profile name/email revisions. Changed identities, inactive scope, unknown policy keys, changed policy versions, stale revisions, and incompatible native user types require review.

Application replaces only that organization/profile's managed grants. An explicitly configured initial profile can replace initial provisioning grants. An empty approved role set withdraws the profile while retaining every other owner and independent local grant. Roles, revisions, and receipts share one transaction; replay returns the original receipt even after policy changes or withdrawal. New operations cannot reuse an already applied account role revision. Credentials, company access, and local profiles stay under receiver control.

Profile synchronization

Local name/email changes advance the source revision and queue an observation in the same transaction, without making a network call. Invalid federation profile values can reject the local change.

This applies to both Users and Contacts, including users sharing the edited contact. One actual change produces one revision and observation per registered account; unchanged values produce none. Direct contact edits cannot bypass stale-update protection or leave invalid native values behind after rejected synchronization. Person correspondence and assignment review reference Core's authoritative peer identity verification; Account independently enforces local user eligibility and access.

Remote profile changes reject administrative, access-rights, public, and service accounts. A shared contact is eligible only when every native user has an active verified account under the same peers, directory owner, and organization scope. Unregistered or independently delegated users require local review. For independent account profiles, use separate native contacts mapped to the same verified person.

Incoming profile.apply requires an existing active verified account, matching peers, owner, complete organization set, and current source revision. Successful application changes only name/email, advances the revision once, and queues an observation. Replays do not repeat the effect.

Names are nonblank and at most 256 characters. Email is a normalized address of at most 254 characters. Identity, access, delegation, and revision are rechecked before delivery.

Access and dependencies

Depends on pmis_federation_transport. System administrators register and archive accounts; ordinary users retain their existing local profile rights. Account links and revisions cannot be replaced through public writes.

Connections require scoped authentication and external runtime binding. See Transport.

Account disablement

An explicitly delegated incoming account.disable connection can disable only a federation-created account belonging to the same provisioning peers and Directory Owner, with matching account/person UUIDs and the full organization set. The native user is archived, a permanent session nonce invalidates old sessions, and all native API keys are removed in the same transaction as the delivery receipt. Local login, password, groups, company grants, and business records are preserved.

Existing locally created accounts, administrators, service users, and accounts with additional company access are rejected for local review. Disabled At records the applied revocation. Replays return durable receipts; fresh requests cannot disable a locally reactivated account again. Old sessions remain invalid after local reactivation. Restoration is not implemented.

Current boundaries

• Provisioning links only explicitly enabled, verified existing users; other collisions need review.

• Disablement applies to an entire eligible federation-created account, not individual roles.

See the repository-wide development backlog.

Account delivery

Profile application changes only existing verified accounts. Account creation uses the separate assigned-provisioning workflow.

The receiver advertises its installed adapters through authenticated, scoped capability discovery. Administrators can reconcile lost observation receipts using Delivery > Outgoing Operations > Reconcile Receipt; the original live local account and connection are checked without repeating hub registration.

Current-state inspection

Delegate account.inspect to a separate incoming connection and service principal. The authenticated POST /pmis/federation/v1/state endpoint compares a verified account's current identity, profile, revisions, native company access, managed groups, withdrawals, and disablement with hub intent. Archived links and disabled users can be inspected for diagnosis. Mismatched account/person/company/peer targets are denied. Results contain only matching checks; inspection never repairs local edits, creates receipts, changes credentials, or repeats a historical disablement.

Receiver access leases

Local Accounts > Review Access Lease optionally sets a receiver-owned deadline within 90 days for exclusively managed, single-company provisioned accounts. Existing linked users and independent local grants cannot be enrolled. Sessions, passwords, XML-RPC credentials, and authenticated HTTP/bearer access fail at expiry even during a hub or scheduler outage. An active minute-based job disables eligible expired users and revokes native sessions/API keys in batches of 100.

Receiver renewal before expiry preserves access. Releasing an unexpired policy permits later independent local grants. Expired accounts need both a new deadline and explicit receiver-approved restoration/assignment replacement; renewal alone does not reactivate them or restore old credentials. Reviews and expiry remain immutable local evidence. See identity review, retention, and leases for eligibility, clock, renewal, and outage behavior.

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