Introduction
Dans Odoo, chaque élément métier — commande, facture, contact — repose sur une structure de données. Ces structures sont décrites par des modèles qui déterminent comment l’information est organisée et stockée dans la base de données.
S’approprier le fonctionnement des modèles est indispensable, que vous soyez consultant fonctionnel ou développeur. Les modèles définissent les champs, les relations et la logique métier : ils forment l’ossature de l’architecture des données d’Odoo.
Pour savoir où Odoo enregistre les métadonnées de tous ces modèles, il faut regarder vers ir.model. Ce modèle sert de registre central : il liste et documente chaque modèle présent dans le système, et c’est souvent le premier endroit que l’on consulte lors du développement, du débogage ou de l’intégration.
Qu’est-ce que le modèle ir.model ?
ir.model est littéralement l’annuaire des modèles dans Odoo : une ligne par modèle décrite dans le système. Qu’un modèle soit défini en Python, généré par Odoo Studio ou ajouté par un module, une entrée ir.model est créée ou mise à jour pour en garder trace.
Ce registre fait partie du cœur d’Odoo et est géré par le module base. Qu’il s’agisse d’un modèle standard, abstrait ou transitoire, il existe une entrée correspondante dans ir.model pour assurer la cohérence du système.
Le modèle ir.model fonctionne main dans la main avec ir.model.fields, qui contient les métadonnées de chaque champ. Ensemble, ces deux tables permettent à Odoo de réfléchir sur sa propre structure — idéal pour l’introspection, les outils dynamiques et les interfaces techniques.
Les développeurs consultent ir.model pour générer des listes de modèles disponibles, analyser l’héritage entre modèles ou créer des outils génériques capables de manipuler n’importe quelle entité. Le registre est accessible via l’API XML-RPC et JSON-RPC pour l’intégration externe.
Champs clés du modèle
Voici un panorama des champs essentiels d’ir.model : les connaître facilite la lecture du registre et les opérations d’introspection sur les modèles Odoo.
name
Type : Char. C’est le libellé lisible du modèle, souvent traduit. On le retrouve dans les paramètres techniques et les outils développeurs — il sert d’étiquette pour repérer rapidement un modèle dans les listes.
model
Type : Char. Le nom technique du modèle (par exemple res.partner ou sale.order). C’est la chaîne utilisée dans le code Python ; elle est obligatoire et indexée pour accélérer les recherches.
info
Type : Text. Zone libre pour des notes ou une description détaillée du modèle. Utile pour la documentation interne mais souvent laissée vide pour les modèles standards.
state
Type : Selection. Indique l’origine du modèle : standard (provenant d’un module Odoo) ou manuel (créé via Studio ou code personnalisé). Les modèles de base sont généralement protégés, les manuels plus facilement modifiables.
transient
Type : Boolean. Si True, le modèle est transitoire : ses enregistrements sont temporaires et nettoyés automatiquement, pratique pour les assistants (wizards) et données éphémères.
field_id
Type : One2many (ir.model.fields). Liste des champs définis pour le modèle. Chaque entrée décrit un champ : nom, type et attributs, ce qui permet une inspection précise au niveau champ par champ.
access_ids
Type : One2many (ir.model.access). Définition des droits d’accès pour le modèle. Chaque règle précise quels groupes peuvent créer, lire, modifier ou supprimer des enregistrements, et constitue la base de la sécurité au niveau modèle.
rule_ids
Type : One2many (ir.rule). Règles d’accès au niveau des enregistrements (record rules) qui limitent la visibilité des lignes pour certains utilisateurs — la sécurité « ligne à ligne ».
inherited_model_ids
Type : Many2many (ir.model). Liste des modèles parents en cas d’héritage. Quand un modèle hérite d’un autre, la relation est référencée ici pour reconstituer la chaîne d’héritage.
modules
Type : Char. Champ calculé indiquant les modules où le modèle est défini ou étendu. Utile pour tracer les dépendances et identifier les origines d’une définition de modèle.
sort
Type : Integer. Ordre d’affichage dans le menu technique. Les valeurs basses s’affichent en premier pour organiser la liste des modèles dans l’interface.
constrains
Type : Text. Définitions Python pour les contraintes (@api.constrains). Y sont stockés les scripts de validation personnalisée au niveau objet.
post_constrains
Type : Text. Contraintes post-validation, utilisées pour des scénarios de validation avancés après la création/modification des enregistrements.
sql_constraints
Type : Text. Contraintes SQL (unique, etc.) appliquées au niveau base de données pour garantir l’intégrité des données.
view_ids
Type : One2many (ir.ui.view). Champ calculé listant les vues liées au modèle, pratique pour la gestion et l’analyse des interfaces utilisateur associées.
record_count
Type : Integer. Champ calculé qui renseigne sur le nombre d’enregistrements présents pour ce modèle — utile pour faire du reporting rapide et jauger le volume de données.
display_name
Type : Char. Champ calculé utilisé pour l’affichage d’un enregistrement dans les listes et relations ; il combine généralement le nom lisible et l’identifiant technique.
create_date
Type : Datetime. Date et heure de création de l’entrée ir.model, gérées automatiquement par Odoo pour l’audit.
create_uid
Type : Many2one (res.users). Utilisateur ayant créé l’enregistrement, utile pour le traçage et l’auditabilité.
write_date
Type : Datetime. Date et heure de la dernière modification, également gérée automatiquement.
write_uid
Type : Many2one (res.users). Utilisateur ayant effectué la dernière mise à jour — encore un champ d’audit standard.
active
Type : Boolean. Indicateur d’archivage (soft delete). Lorsqu’il est à False, le modèle est considéré déprécié et masqué par défaut.
id
Type : Integer. Identifiant unique en base pour chaque enregistrement ir.model, utilisé dans les appels API et références internes.
restrict_functionality
Type : Boolean. Indique si certaines fonctionnalités du modèle sont limitées selon l’édition d’Odoo (community vs enterprise).
is_mail_thread
Type : Boolean. Signale si le modèle incorpore le mécanisme de messagerie/chatter (messages, abonnés) pour gérer les discussions.
is_mail_activity
Type : Boolean. Indique si le modèle supporte le module d’activités (planificateur d’actions, suivi des prochaines actions).
Utilisations courantes dans les processus métiers
1. Paramétrage technique et configuration
Les administrateurs parcourent le menu Technique pour explorer les modèles ; les enregistrements ir.model déterminent l’affichage de cette liste (nom, description, nombre de champs), facilitant l’administration et la maintenance du système.
2. Gestion des droits d’accès
Pour sécuriser l’application, on attribue des droits aux groupes : les access_ids d’ir.model définissent qui peut créer, lire, modifier ou supprimer pour un modèle donné — base de la gouvernance des accès.
3. Personnalisation avec Odoo Studio
Quand un utilisateur crée un modèle via Studio, Odoo génère automatiquement une entrée ir.model en état « manuel » et y rattache les champs créés, simplifiant la personnalisation sans écrire de code.
4. Découverte pour API et intégrations
Les systèmes externes peuvent interroger ir.model via XML-RPC ou JSON-RPC pour découvrir les modèles disponibles et leur structure, plutôt que d’utiliser des noms codés en dur — meilleure approche pour des intégrations robustes.
5. Développement et débogage de modules
Les développeurs consultent ir.model pour comprendre les héritages (inherited_model_ids) et inspecter les champs (field_id) lors de la création ou du diagnostic de modules, ce qui aide à maintenir la cohérence fonctionnelle.
Comment les développeurs étendent ce registre
Les développeurs n’ont généralement pas à modifier ir.model lui-même : le registre est mis à jour automatiquement lors du chargement d’un module. On interagit plutôt avec les modèles décrits par ir.model pour personnaliser le comportement métier.
Héritage des modèles
Lorsqu’une classe Python définit _inherit = 'res.partner', Odoo met à jour l’enregistrement correspondant dans ir.model pour refléter le lien parent-enfant. Cette mise à jour permet de reconstituer la hiérarchie d’héritage et d’assurer que les prolongations de modèles restent cohérentes.
Ajout de champs
L’ajout de nouveaux champs crée des enregistrements dans ir.model.fields, qui pointent vers ir.model via model_id. L’ir.model sert de conteneur, mais les définitions détaillées des champs sont gérées séparément.
Extensions Python
On n’override presque jamais les méthodes d’ir.model : il fait partie du noyau. Si vous devez modifier un comportement, étendez plutôt les modèles métiers décrits par le registre, pas le registre lui‑même.
Odoo Studio
Odoo Studio automatise la création des enregistrements ir.model et ir.model.fields pour les modèles personnalisés. Le drapeau transient distingue les modèles temporaires. Notez que les modèles abstraits ne créent pas d’entrée ir.model car ils n’ont pas de table en base.
Bonnes pratiques
- Pour les intégrations, utilisez ir.model pour découvrir dynamiquement les modèles plutôt que d’encoder des noms fixes : c’est plus souple et diminue les risques de rupture lors d’évolutions du schéma.
- Préférez la recherche par le champ model pour vos requêtes : ce champ est indexé et permet des recherches rapides du registre lorsque vous cherchez les métadonnées d’un modèle précis.
- Avant d’étendre un modèle, inspectez inherited_model_ids pour comprendre la chaîne d’héritage. Cela évite les conflits et vous aide à positionner correctement vos ajouts.
- Utilisez les accès API exposés (XML-RPC/JSON-RPC) pour lire ir.model lorsque vous automatisez la découverte, et n’appliquez pas de modifications directes au registre sauf si vous développez un outil de type Studio.
- Pour l’introspection au niveau des champs, interrogez ir.model.fields via le relation field_id : vous obtiendrez la liste complète des champs et leurs propriétés pour un modèle donné.
Erreurs fréquentes
- Modifier directement les enregistrements ir.model est risqué : le registre est géré par Odoo et vos changements peuvent être écrasés lors d’un upgrade ou casser la cohérence du système.
- Ne confondez pas la fiche ir.model avec la classe Python : ir.model est l’enregistrement en base qui décrit le modèle, la classe Python est l’implémentation active qui exécute la logique métier ; les deux sont liés mais distincts.
- N’imaginez pas que tous les modèles ont une entrée ir.model : les modèles abstraits (sans table) n’apparaissent pas dans le registre car ils ne correspondent pas à une table physique en base.
- Souvenez-vous que les modèles transitoires sont éphémères : le flag transient signifie que les données seront purgées automatiquement, donc on n’y stocke pas d’informations à conserver sur le long terme.
- Évitez d’interroger ir.model sans filtres : une instance Odoo comporte souvent des centaines de modèles. Filtrez toujours par nom de modèle ou utilisez des domaines de recherche pertinents.
Conclusion
En résumé, ir.model est le registre central des modèles Odoo : il contient les métadonnées nécessaires pour comprendre la structure du système et, couplé à ir.model.fields, il permet d’explorer l’architecture des données.
Que vous gériez la configuration depuis l’interface technique ou que vous développiez une intégration API, maîtriser ir.model vous fera gagner du temps et évitera des erreurs coûteuses.
Besoin d’aide pour votre implémentation Odoo ?
Dasolo accompagne les entreprises dans le déploiement, la personnalisation et l’optimisation d’Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une solide maîtrise de l’architecture et des modèles comme ir.model.
Si vous souhaitez de l’aide pour votre implémentation Odoo, la création de modules personnalisés ou des intégrations, notre équipe est à votre disposition. Demandez une démo pour discuter de votre projet.