Skip to content

Terminology

This page defines the canonical terms used across the dirac-odoo design documents so SA/PA discussions do not drift in meaning between pages.

Core Concepts

Term Definition Notes
Serviced Account (SA) Governance boundary for access, assignment, visibility, and authority In this repo, SA always means Serviced Account
Portal App (PA) The SA-governed portal form of OVApp; the user-facing application layer that establishes the active {actor, sa} context and drives governed CRUD through proxy execution PA and OVApp are not separate apps in this documentation set
actor The human user operating inside the current SA context actor is the within-SA assignment boundary
sa The selected serviced account on whose behalf actions are taken sa is the tenancy and organizational boundary
{actor, sa} The governing context pair used for attribution, filtering, and operational scope This pair is a recurring design invariant in this repo
membership The relationship that grants a person authority within a serviced account Authority lives on membership, not directly on the identity record
SA Administration (SAA) Administrative authority that governs SA structure and integrity Distinct from ordinary business management inside the SA
SA Management (SAM) Business-management activity performed through the valid SA and membership structures Consumes the structure maintained by SAA
sa_manager The current root member of one SA's membership tree Same membership type as others; distinguished by scope and tree position
SA_ROOT The system root SA above all SA<x> roots Proper SA used as the top node of the SA tree
SA<x> Canonical branch-root SA for one OV<x> company domain Example: SAT, SAK, SAPH naming pattern by company branch
current SA The serviced account currently selected in PA Visibility checks begin here
current actor The actor currently operating in PA App policy may further restrict visibility by actor

Acronyms And Platform Terms

Term Meaning Current Usage
ERP Enterprise Resource Planning Refers to native Odoo transaction and logistics behavior
CRUD Create, Read, Update, Delete Basic application operations on governed records
RBAC Role-Based Access Control General access-control concept; not fully modeled in v0
SSO Single Sign-On Future identity/authentication concern; deferred in v0
IdP Identity Provider External identity source such as Microsoft / Entra
BFF Backend for Frontend Application/API layer used by PA or related clients
UXI User Experience Interface Front-end/app layer in the broader DIRAC stack
OVApp The application surface through which portal and field workflows are exposed In SA-governed contexts, OVApp is the Portal App (PA) rather than a separate application
CRM Customer Relationship Management Odoo-side customer/contact lifecycle context
OVAC Omnivoltaic-affiliated account class Serviced-account class for affiliated/subsidiary governance contexts
EXTC External customer account class Serviced-account class for external client/customer contexts
DIRAC DIRAC framework / platform context Broader architecture in which Odoo, PA, and governance models sit
Odoo Odoo ERP platform System of record for transactions, inventory, accounting, and logistics

Usage Rules

  • Use Serviced Account and Portal App as the expanded forms when first introducing SA and PA in a page.
  • When both names appear, treat Portal App (PA) as the SA-governed portal form of OVApp, not as a separate app.
  • Use SA Administration and SA Management as the expanded forms when first introducing SAA and SAM in a page.
  • Treat ov.* as the technical namespace for custom Odoo models in this repo.
  • Do not infer direct semantic coupling between two models only because both use the ov.* prefix.
  • Use documented fields, invariants, and responsibilities to define relationships between ov.* models.
  • Treat the terminology on this page as the canonical meaning unless a document explicitly narrows a term for a local reason.
  • Avoid typo variants such as Partal App or Services Account.

Operation Labels

Use reader-facing imperative labels for membership-management actions:

  • Release Team
  • Release Customers
  • Reassign Team Member
  • Reassign Customer
  • Change SA Manager

Use normalized snake_case names for implementation-facing identifiers:

  • release_team
  • release_customers
  • reassign_team_member
  • reassign_customer
  • change_sa_manager