Skip to content

Repo Boundaries

This page defines how dirac-odoo fits with the adjacent DIRAC documentation repos.

Primary Role

dirac-odoo is the developer-facing repository for Odoo and ERP semantics.

It should be the primary place to document:

  • Odoo object behavior and extension strategy
  • inventory, sales, CRM, and people semantics
  • serviced-account and portal-governance behavior inside Odoo
  • ERP transaction, visibility, affiliation, and synchronization rules
  • custom ov.* model design where native Odoo models are insufficient

What Belongs In Adjacent Repos

dirac-abs should own:

  • asset lifecycle and asset-state behavior
  • entitlement and bundle behavior on the ABS side
  • IoT, device, and field-service workflow semantics
  • ABS-side operational history and service execution logic

emob-commercial-models should own:

  • operations-facing commercial model definitions
  • pricing, offer structure, rollout, and SOP guidance
  • business-facing bundle and product-unit framing
  • process expectations that developers later implement through Odoo and ABS

Handoff Rules

When a topic crosses repo boundaries, keep the split explicit:

  • document ERP/Odoo behavior here
  • document ABS operational behavior in dirac-abs
  • document commercial operating intent and SOP framing in emob-commercial-models

If the same concept appears in more than one repo, this repo should explain the Odoo meaning rather than restating the ABS execution meaning or the commercial operating playbook.

Shared Invariants

  • PA is the correct current term for the portal application surface. OVApp is a legacy term and should only appear where historical reference is necessary.
  • Entitlement is authorized by Odoo business transactions and enforced/substantiated by ABS in physical and IoT operations.
  • Pricing source of truth remains in Odoo.
  • service template is reserved for commercial and operational packaging in emob-commercial-models.
  • service model is reserved for runtime ABS behavior in dirac-abs.
  • No ov.asset is needed at this stage for SA context.
  • Current asset anchoring should use Odoo stock and inventory constructs: a location hosts a collection of serials, and Odoo ensures one unique location for an asset at a given time.

Conflict Resolution

When repos disagree, use this tie-break rule:

  • functional intent conflicts are resolved by emob-commercial-models
  • Odoo implementation conflicts are resolved by dirac-odoo
  • ABS implementation conflicts are resolved by dirac-abs

Short Form

  • dirac-odoo explains how the ERP side works in Odoo.
  • dirac-abs explains how asset-based services work in ABS.
  • emob-commercial-models explains what operations and commercial teams need both systems to deliver.