Introduction
Lorsque vous commencez à travailler avec le développement Odoo, un concept revient sans cesse : l'héritage. L'ORM d'Odoo est construit autour de l'idée que les modèles peuvent étendre, partager et réutiliser les champs des autres sans dupliquer les données ni écrire du code redondant.
Les champs hérités sont centraux dans ce système. Ils permettent à un modèle d'accéder et d'exposer de manière transparente des champs qui sont physiquement définis et stockés sur un autre modèle. Une fois que vous comprenez ce mécanisme, beaucoup de choses dans le modèle de données Odoo commencent à avoir du sens.
Ce guide explique ce que sont les champs hérités, les trois types d'héritage de modèle qui les produisent, comment ils se comportent dans la base de données et comment vous pouvez les utiliser dans de réels projets de personnalisation Odoo.
Qu'est-ce qu'un champ hérité dans Odoo ?
Dans le cadre du framework ORM d'Odoo, un champ est considéré comme hérité lorsqu'un modèle accède à des champs définis sur un autre modèle via l'un des trois mécanismes d'héritage pris en charge. Au lieu de redéfinir ces champs depuis le début, le modèle enfant les réutilise simplement.
C'est une partie de ce qui rend le modèle de données d'Odoo si compact et cohérent. Le même champ name sur un enregistrement de partenaire est celui qui apparaît sur les commandes de vente, les pistes CRM et les factures, car tous ces modèles lisent finalement à partir de la même source.
Les trois types d'héritage dans Odoo
Odoo prend en charge trois types distincts d'héritage de modèle, et chacun gère les champs différemment.
1. Héritage classique
C'est le modèle le plus courant dans le développement Odoo. Vous utilisez _inherit sans définir un nouveau _name. Cela étend un modèle existant directement, en ajoutant de nouveaux champs ou méthodes. Aucune nouvelle table de base de données n'est créée. Les nouveaux champs apparaissent simplement sur le modèle original.
C'est ainsi que la plupart des modules Odoo ajoutent des champs aux modèles standards. Si vous installez le module CRM, il ajoute des champs à res.partner par héritage classique. Ces champs sont stockés dans la table partenaire aux côtés des champs principaux.
2. Héritage par prototype
C'est lorsque vous combinez _inherit et _name ensemble. Le nouveau modèle commence comme une copie de la structure du modèle parent, mais obtient sa propre table de base de données. Tous les champs parent sont dupliqués dans le nouveau modèle. Les modifications apportées au modèle enfant n'affectent pas le parent.
Ce modèle est moins courant dans la personnalisation quotidienne mais est utilisé pour créer des modèles entièrement nouveaux qui partagent la structure d'un modèle existant.
3. Héritage par délégation
C'est le type le plus distinctif, défini à l'aide de _inherits. Le modèle enfant se lie à un modèle parent via un champ Many2one. Le modèle enfant expose ensuite de manière transparente tous les champs du parent comme s'ils étaient les siens. Les données résident dans la table du parent, pas dans celle de l'enfant.
C'est ce que la plupart des développeurs entendent par champs hérités au sens strict. Les champs ne sont pas dupliqués. Ils sont accessibles via le lien relationnel au moment de la lecture et de l'écriture.
L'exemple le plus célèbre dans Odoo standard est la relation entre res.users et res.partner. Chaque utilisateur est également un partenaire. Le nom, l'email et le numéro de téléphone de l'utilisateur sont stockés dans l'enregistrement du partenaire et accessibles par l'utilisateur via l'héritage par délégation.
Comment fonctionne le champ
Héritage par Délégation Sous le Capot
Lorsqu'un modèle utilise _inherits, l'ORM d'Odoo crée un pont transparent entre deux tables de base de données. Lorsque vous lisez un champ hérité dans l'enregistrement enfant, Odoo suit automatiquement le lien Many2one vers l'enregistrement parent et renvoie la valeur stockée là.
Lorsque vous écrivez dans un champ hérité depuis le modèle enfant, Odoo écrit directement dans l'enregistrement parent. Du point de vue du développeur, le champ semble natif. Du point de vue de la base de données, les données vivent dans la table parent.
Cela a une conséquence importante : il n'y a pas de duplication de données. Si vous mettez à jour le nom d'un partenaire, ce changement se reflète immédiatement partout où le partenaire est référencé, y compris dans l'enregistrement utilisateur qui en hérite.
Héritage Classique et la Base de Données
Avec l'héritage classique, de nouveaux champs sont ajoutés à la table de base de données du modèle original. Il n'y a pas de seconde table impliquée. Le modèle étendu et le modèle original sont la même chose dans la base de données. C'est la manière la plus propre et la plus courante d'ajouter des champs dans les projets de personnalisation Odoo.
Champs Liés comme Héritage Léger
Un champ related est un type spécial de champ calculé dans l'ORM d'Odoo qui lit une valeur d'un enregistrement lié à travers une chaîne de champs relationnels. Ce n'est pas strictement la même chose que l'héritage de modèle, mais il est souvent utilisé pour faire ressortir des données de style hérité sur un modèle sans modifier la structure du modèle.
Par exemple, vous pourriez définir un champ partner_country_id sur une commande de vente qui lit partner_id.country_id. Le champ se comporte comme un champ natif sur la commande de vente, mais la valeur provient du partenaire.
Les champs liés peuvent être stockés dans la base de données avec store=True, ce qui améliore les performances de recherche et de filtrage mais ajoute un surcoût de stockage et nécessite une recomputation lorsque la source change.
Comment les champs sont résolus à l'exécution
Lorsque Odoo charge une définition de modèle, il résout la carte complète des champs, y compris tous les champs hérités. Au moment où un modèle est prêt à être utilisé, Odoo a déjà mappé chaque champ accessible à sa source, que cette source soit la propre table du modèle, une table parente via délégation, ou une chaîne liée. Cette résolution se produit une fois au démarrage du serveur et est mise en cache pour des performances optimales.
Cas d'utilisation commerciale
Les champs hérités ne sont pas seulement un concept technique. Ils résolvent de réels problèmes commerciaux en maintenant les données cohérentes à travers différentes parties d'Odoo sans duplication.
1. CRM et Ventes : Informations de Contact
Lorsqu'un commercial crée un prospect dans le module CRM, le nom du client, le numéro de téléphone et l'adresse e-mail proviennent de l'enregistrement du partenaire via un lien Many2one. Si les détails du partenaire changent, chaque prospect, devis et commande lié à ce partenaire reflète immédiatement la mise à jour.
C'est l'héritage classique et les champs liés qui fonctionnent ensemble. Le module CRM étend res.partner avec des champs spécifiques au CRM (comme le nombre de prospects et le stade d'opportunité), et les commandes de vente affichent les informations de contact du partenaire à travers des champs liés.
2. Produits et Variantes
Le modèle de produit d'Odoo utilise l'héritage par délégation pour gérer proprement les variantes de produit. Le modèle product.product (une variante spécifique) utilise _inherits pour se lier à product.template. Les champs partagés entre toutes les variantes, tels que le nom du produit, la catégorie, le prix de vente et la description, se trouvent sur le modèle. Les champs spécifiques aux variantes comme le code-barres ou la référence interne se trouvent sur l'enregistrement de la variante elle-même.
Ce design signifie que vous pouvez avoir 50 variantes de couleur d'une chemise, toutes partageant le même nom et la même description, sans stocker ces valeurs 50 fois dans la base de données.
3. Utilisateurs et Partenaires
Chaque utilisateur Odoo est également un contact. Le modèle res.users utilise _inherits = {'res.partner': 'partner_id'}, ce qui signifie que l'utilisateur hérite automatiquement de tous les champs du partenaire, y compris le nom, l'e-mail, le téléphone, l'adresse et la photo de profil. Lorsque vous mettez à jour l'adresse e-mail d'un employé, elle se met à jour à la fois dans les paramètres de l'utilisateur et dans le carnet d'adresses en même temps.
4. Inventaire : Mouvements de Stock et Informations sur les Produits
Les lignes de mouvement de stock dans le module Inventaire affichent des descriptions de produits qui proviennent du modèle de produit à travers une chaîne de champs liés. Les responsables d'entrepôt voient des informations produit précises et à jour directement dans leurs listes de prélèvement sans que le module d'inventaire ait besoin de dupliquer les données produit.
5. Comptabilité : Lignes de Facture
Les lignes de mouvement de compte font référence à des produits et des partenaires. Le nom du produit, les codes de compte et les configurations fiscales affichés sur une ligne de facture proviennent des modèles de produit et de partenaire à travers des liens relationnels et des champs associés. Les comptables voient des données cohérentes qui correspondent à ce que les équipes de vente ont configuré sur le produit, car ils lisent à partir de la même source.
Créer ou personnaliser des champs hérités
Utilisation d'Odoo Studio
Odoo Studio est l'interface sans code pour personnaliser les modèles et les vues d'Odoo. Depuis Studio, vous pouvez ajouter de nouveaux champs à n'importe quel modèle sans écrire de code Python. Ce que Studio fait en coulisses est l'héritage classique : il étend le modèle en ajoutant un nouveau champ à sa définition.
Studio vous permet également de créer des champs liés. Lorsque vous choisissez "Champ Lié" comme type de champ, vous pouvez pointer vers n'importe quel champ accessible à travers une chaîne relationnelle depuis le modèle actuel. Par exemple, sur le modèle de commande de vente, vous pouvez créer un champ lié qui lit le pays ou le numéro de TVA du client directement à partir de l'enregistrement du partenaire.
Pour la plupart des utilisateurs commerciaux et des consultants fonctionnels, Studio est le bon outil pour ajouter des champs à Odoo. Il gère automatiquement la nomination des champs, la migration de la base de données et le placement des vues.
Personnalisation Technique avec Python
Pour les développeurs construisant des modules Odoo, les champs hérités sont définis en Python en utilisant la classe models.Model de l'ORM Odoo.
Héritage classique pour ajouter un champ personnalisé à un modèle existant :
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Valeur Estimée du Contrat'
)Héritage par délégation pour créer un nouveau modèle qui partage des champs d'un modèle existant :
class EmployeeProfile(models.Model):
_name = 'hr.employee.profile'
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one(
'res.partner',
required=True,
ondelete='cascade'
)
employee_id = fields.Many2one(
'hr.employee',
string='Employé'
)Champs liés pour faire ressortir une valeur d'un enregistrement lié :
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Pays du client',
store=True
)Via l'API XML-RPC (Configuration à distance)
Des champs peuvent également être ajoutés par programmation en utilisant l'API XML-RPC d'Odoo et le modèle ir.model.fields. C'est l'approche utilisée dans les carnets de configuration à distance de Dasolo. Cela équivaut à ce que fait Studio, et cela permet la création de champs sans accès direct au serveur.
Pour ajouter un champ lié via l'API, vous créez un enregistrement ir.model.fields avec ttype='many2one' (ou le type approprié) et définissez le paramètre related pour définir le chemin relationnel. Cette approche est bien adaptée pour déployer des champs personnalisés dans le cadre d'un processus de configuration automatisé.
Meilleures pratiques
Choisissez le bon type d'héritage pour le travail
Utilisez l'héritage classique lorsque vous souhaitez simplement ajouter des champs ou des méthodes à un modèle existant. C'est l'approche la plus simple et c'est ce que la grande majorité des modules Odoo utilisent. Réservez l'héritage par délégation pour les cas où vous avez réellement besoin de deux ensembles d'enregistrements distincts liés ensemble, comme lorsque un concept commercial étend un contact sans être un contact lui-même.
Préférez les champs liés pour l'accès en lecture
Si vous avez seulement besoin d'afficher une valeur d'un enregistrement lié sur un formulaire ou une vue en liste, un champ lié est plus propre qu'un héritage par délégation. Cela évite de créer une nouvelle dépendance structurelle et est facile à comprendre et à maintenir.
Soyez prudent avec store=True sur les champs liés
Stocker un champ lié dans la base de données accélère les recherches et les filtres, mais cela signifie que la valeur est une copie. Odoo déclenche une recomputation lorsque la source change, mais dans des cas extrêmes, cela peut devenir désynchronisé. Ne stockez des champs liés que lorsque vous avez réellement besoin de filtrer ou de trier par eux à grande échelle.
Toujours préfixer les champs personnalisés avec x_
Tout champ que vous ajoutez à un modèle Odoo standard par héritage doit commencer par x_ (ou utiliser un espace de noms de module dans un module approprié). Cela empêche les conflits avec les champs ajoutés par Odoo dans les futures versions.
Documentez votre chaîne d'héritage
Lorsque vous travaillez sur des personnalisations complexes, écrivez un bref commentaire ou une note de conception expliquant d'où viennent les champs et pourquoi. Un champ nommé x_country_code sur une commande de vente peut ne pas être clairement lié à partner_id.country_id.code sans documentation.
Gérez correctement les suppressions en cascade
Dans l'héritage par délégation, l'enregistrement parent est créé automatiquement lorsque l'enfant est créé. Lorsque l'enfant est supprimé, le parent doit généralement être supprimé aussi. Définissez ondelete='cascade' sur le Many2one dans _inherits pour garantir une suppression propre sans enregistrements orphelins.
Pièges courants
Confondre les trois types d'héritage
L'erreur la plus courante pour les développeurs nouveaux dans Odoo est d'utiliser _inherit avec _name lorsqu'ils avaient l'intention d'utiliser l'extension classique. Cela crée accidentellement un tout nouveau modèle au lieu d'étendre l'existant. Vérifiez votre définition de modèle : si vous n'avez pas l'intention de créer un nouveau modèle, omettez _name.
Oublier de créer l'enregistrement parent dans _inherits
Avec l'héritage par délégation, l'enregistrement parent ne se crée pas automatiquement dans tous les scénarios. Lors de la création d'un enregistrement enfant par programme via l'API ou dans un script, vous devez soit laisser l'ORM d'Odoo gérer la création du parent (ce qu'il fait lorsque vous utilisez create normalement), soit créer d'abord l'enregistrement parent et passer son ID. Ignorer cette étape entraîne une erreur de contrainte de base de données.
Essayer de changer le type d'un champ par héritage
Odoo n'autorise pas le remplacement du type d'un champ existant par héritage. Vous pouvez changer des attributs comme l'étiquette de chaîne, le domaine ou le texte d'aide, mais vous ne pouvez pas changer un champ Char en un champ Integer. Tenter cela entraînera une erreur d'installation de module.
Utilisation excessive des champs liés stockés
Ajouter store=True à chaque champ lié est tentant pour des raisons de performance, mais cela augmente la taille de la base de données et introduit une surcharge de maintenance. Si le champ source change fréquemment, les champs liés stockés déclenchent beaucoup de recomputation. Utilisez les champs liés stockés de manière sélective, uniquement lorsque vous avez un besoin concret de filtrer ou de regrouper par eux dans de grands ensembles de données.
Supposer que les champs hérités respectent les règles d'accès du modèle enfant
Les champs hérités par délégation vivent sur le modèle parent. Les droits d'accès définis sur le modèle enfant ne s'appliquent pas automatiquement à ces champs au niveau de la base de données. Si vous restreignez l'accès au modèle enfant mais pas au parent, les utilisateurs peuvent toujours lire les valeurs des champs hérités directement via le modèle parent. Passez toujours en revue les règles de sécurité pour les deux modèles lors de l'utilisation de l'héritage par délégation.
Conclusion
Les champs hérités ne sont pas une fonctionnalité de niche du développement Odoo. Ils sont intégrés dans l'architecture du système. La relation entre les utilisateurs et les partenaires, entre les variantes de produits et les modèles, entre les commandes de vente et les informations de contact des clients : tout cela repose sur l'héritage des champs pour maintenir la cohérence des données et éviter la duplication.
Comprendre quel type d'héritage utiliser, quand utiliser un champ lié à la place, et comment ces mécanismes se comportent dans la base de données vous rendra significativement plus efficace en tant que personnaliseur Odoo. Vous écrirez un code plus propre, concevrez de meilleurs modèles de données et passerez moins de temps à déboguer un comportement inattendu des champs.
L'essentiel est simple : l'ORM d'Odoo est conçu de sorte que les champs vivent à un seul endroit et soient accessibles depuis plusieurs. C'est le principe derrière les champs hérités, et c'est ce qui maintient le modèle de données d'Odoo cohérent même lorsqu'il se développe à travers des dizaines de modules interconnectés.
Besoin d'aide pour votre implémentation Odoo ?
Chez Dasolo, nous aidons les entreprises à mettre en œuvre, personnaliser et optimiser Odoo. Que vous construisiez un module personnalisé à partir de zéro, que vous étendiez des modèles standard avec de nouveaux champs, ou que vous essayiez de comprendre pourquoi votre modèle de données se comporte de manière inattendue, notre équipe a l'expérience pratique d'Odoo pour vous aider à avancer plus rapidement et à éviter des erreurs coûteuses.
Si vous avez des questions sur votre modèle de données Odoo, votre stratégie de champs personnalisés ou votre mise en œuvre technique, nous serions ravis de discuter de votre situation. Contactez-nous et trouvons la bonne approche pour votre projet.