ADR 0001: Governance Model Progression (V1 -> V2 -> V3)¶
Status¶
Accepted
Context¶
This handbook documents three generations of customer governance in Odoo:
- V1 foundation (Service Accounts, memberships, role-based access)
- V2 compatibility stamps (
x_sa_id,x_actor_id) - V3 association tables (for example
ov.sa_customer_assignment)
Without an explicit architectural decision, teams can treat all three models as equally authoritative, which leads to conflicting reads, unsafe writes, and inconsistent lifecycle handling.
Decision¶
Adopt V3 association tables as the canonical source of truth for governed assignments and lifecycle history.
Use V2 stamps only as a compatibility bridge for legacy integrations and transitional read paths.
Keep V1 concepts (Service Accounts, memberships, roles) as identity and governance primitives, not assignment history storage.
Consequences¶
- New workflow design must anchor assignment state and history in V3 association tables.
- Integration and migration work must prefer V3 reads whenever available.
- Legacy consumers that still rely on V2 stamps remain supported during transition, but do not define authoritative state.
- Documentation should clearly separate "canonical state" from "compatibility state" in every workflow that references assignment data.