Skip to content

Dirac-Odoo Landscape

This page maps dirac-odoo's place in the DIRAC architecture and cross-references its key ADRs and design concepts.

Role

dirac-odoo is the developer-facing repository for Odoo and ERP semantics within the DIRAC platform. It handles inventory, sales, CRM, people, and ERP-side model behavior, including the Serviced Account (SA) governance model and custom ov.* namespace models.

Evolution: V0 → V1 → V2 → V3

The repo follows a named refinement progression:

Phase Focus Status
V0 Initial SA construction model Historical reference
V1 SA construction with native Odoo patterns Historical reference
V2 Externalized SA scoping via association tables Migration target
V3 Association-model pattern as default for new scope Current default

Developers should treat V3 as the current default for any new SA visibility scope.

Active Architecture Decisions

The repo maintains 8 ADRs:

ADR Title Status Key Concept
0001 V1 SA Construction Model Accepted Original SA model design
0002 ov.* Model Namespace and Semantic Independence Accepted Custom model namespace rules
0003 V3 Association-Model Migration Pattern Accepted Current default: externalized association tables over native Odoo stamping
0004 Fleet and Item Governance Layer Accepted Fleet-member associations for operational grouping
0005 V3 SA-POS Governance Draft POS retail governance under V3 pattern
0006 SA Access Security Foundation Proposed Track A (auth) / Track B (authz) security hardening
0007 Asset Registry and Component Model Accepted Odoo implementation of ov.asset.registry and ov.asset.component
0008 Assembly-Cell Process with SA Governance Proposed SA = Production Location; Cell vs. Line production distinction

Cross-Repo Boundary

From dirac-odoo's repo boundary definition:

  • dirac-odoo documents how the ERP side works in Odoo
  • dirac-abs documents how asset-based services work in ABS
  • emob-commercial-models documents what operations and commercial teams need both systems to deliver
  • dirac-fed provides the BFF layer that UXI apps consume; Odoo-to-FED mappings live there

Key Design Principles

  • PA is the current term for the portal application surface (OVApp is legacy)
  • Entitlement is authorized by Odoo, enforced/substantiated by ABS
  • Pricing source of truth is in Odoo
  • No generic ov.asset wrapper is needed by default
  • Physical asset anchoring stays in Odoo stock constructs (location, serial/lot, state, movement)
  • Dedicated ov.fleet layer only when operational grouping must be distinct from physical location