Odoo
Les versions couvertes.
Le travail de TraQL porte sur une version d'Odoo à la fois : les règles de calcul sont lues dans le code source de cette version, et une montée de version peut les déplacer. Chaque page ci-dessous dit ce qui a été mesuré, et sur quelle base.
Ce que TraQL sait faire sur Odoo
TraQL lit les règles de calcul là où Odoo les applique — dans les rapports et les règles d'enregistrement qui sortent le chiffre — et les écrit dans ses propres fichiers de déclaration, avec le fichier et la ligne d'origine.
Il produit alors la requête qui répond à votre question, la règle qu'il a appliquée, et les autres réponses qu'Odoo donne lui-même à la même question, avec ce que chacune compte en trop.
Ce travail est refait à chaque version majeure : une montée de version peut déplacer une règle. C'est pourquoi il y a une page par version.
Les particularités d'Odoo
Le périmètre — la colonne company_id, et c'est une liste.
Odoo écrit sa règle de société comme ('company_id', 'parent_of', company_ids),
et cette liste vient de la session ou du compte de
celui qui regarde. TraQL n'a ni session ni compte Odoo : la liste se
déclare, dans entite.valeur de base-odoo.json. Un second
champ, entite.reference, dit de quelle société on lit un réglage — ces
lectures veulent une ligne, pas un ensemble.
Et une règle d'Odoo se reprend en entier : chez lui, un company_id
vide ne veut pas dire « rattaché à aucune société » mais « partagé entre toutes ».
Cette branche-là est triviale à écrire en SQL, et ce qu'elle vaut a été mesuré le
31 août 2026 sur la base d'épreuve : avec elle, TraQL répond 2 clients et
44 articles ; sans elle, zéro et zéro.
Ce n'est pas une formalité, c'est toute la réponse. Elle est
aujourd'hui écrite en SQL, en toutes lettres, table par table, à côté de sa source dans
le code d'Odoo.
L'exercice — deux colonnes sur la société, et c'est l'inverse de
Dolibarr. Dolibarr range une constante globale et déclare le
premier mois. Odoo range deux colonnes sur
res_company — fiscalyear_last_month et
fiscalyear_last_day — et déclare le dernier jour : un
mois et un quantième. La différence change le chiffre, et elle est déclarée plutôt que
dérivée. TraQL lit ces colonnes dans votre base au moment du scan et fige ce qu'il a
trouvé.
La devise — la colonne currency_id, qui est une clé.
Chez Odoo elle ne porte pas le code de la monnaie mais un renvoi vers la table des
devises ; le code se lit là-bas, par un chemin déclaré. Quand la table interrogée ne
porte aucune devise — c'est le cas de crm_lead — TraQL pose une valeur
déclarée, 'EUR' AS devise, et le dit.
Et quand il somme une colonne sans pouvoir borner la devise, il ne se tait pas :
il écrit UNITÉ NON BORNÉE à la place, parce qu'un montant dont on ignore
l'unité ne se défend pas. Vous en verrez un exemple mesuré sur la page de version.
Les tiers — qui voit quoi. TraQL suppose que celui qui interroge voit
tous les tiers : droits.tous_les_tiers vaut
true. Contrairement à Dolibarr, aucune table de restriction par
commercial n'est déclarée du côté d'Odoo — l'hypothèse est la même, ce qu'il faudrait
déclarer pour la lever ne l'est pas.
Ce que TraQL ne fait pas sur Odoo
Il lui faut un accès direct à la base. TraQL lit PostgreSQL ; il n'interroge ni l'interface d'Odoo, ni son service web. Un hébergement qui n'ouvre pas sa base — Odoo Online — ne convient donc pas.
Il ne dit pas si votre Odoo est en édition Community ou Enterprise.
Cette information ne se lit pas en base : le gabarit qui l'affiche l'écrit en dur et ne
consulte aucune table. Il existe un indice dans ir_module_module.license,
mais un indice présenté comme un constat est exactement ce que TraQL refuse de faire.
Il ne choisit pas le périmètre à la question. Puisqu'il n'a ni session ni compte, il lit un périmètre déclaré, le même pour toutes les questions. Un utilisateur qui ne verrait qu'une société chez son éditeur en verra ici toutes celles qui sont déclarées.
Les versions couvertes
Ces informations ont été relevées le 31 août 2026, sur le dépôt
au commit 17d9143.