Introduction
Si vous avez déjà enregistré un formulaire dans Odoo et vu un champ devenir rouge, vous avez déjà rencontré le mécanisme de champ requis. C'est l'une des fonctionnalités les plus fondamentales du modèle de données Odoo et l'une des manières les plus simples d'assurer la qualité des données dans vos flux de travail commerciaux.
Que vous configuriez Odoo pour une équipe de vente, que vous mettiez en place un modèle personnalisé ou que vous travailliez sur un projet de développement technique Odoo, comprendre comment fonctionne l'attribut required vous aidera à construire des processus plus fiables.
Ce guide couvre tout : comment le champ se comporte dans le cadre Odoo, comment le configurer en utilisant Odoo Studio ou du code Python, quand l'utiliser et quelles erreurs éviter.
Quel est le champ requis dans Odoo
Dans Odoo, l'attribut required est une contrainte au niveau du champ qui empêche un enregistrement d'être enregistré à moins que le champ ne contienne une valeur. Il s'applique à pratiquement tous les types de champs Odoo : champs de texte, champs numériques, champs de sélection, champs many2one, dates, et plus encore.
Il fait partie du modèle de données Odoo de base et est l'un des attributs les plus couramment utilisés lors de la personnalisation d'Odoo. Définir un champ comme requis est la première ligne de défense contre des données incomplètes ou incohérentes dans votre base de données.
Comment cela apparaît dans l'interface
Dans l'interface utilisateur d'Odoo, les champs requis sont visuellement distingués des champs optionnels. Lorsqu'un formulaire est en mode édition, les champs requis affichent généralement un indicateur visuel subtil. Lorsqu'un utilisateur essaie d'enregistrer l'enregistrement sans remplir un champ requis, Odoo met en surbrillance le champ en rouge et affiche un message d'avertissement.
Ce comportement est cohérent à travers l'interface web. Les utilisateurs voient un retour d'information immédiat et clair, ce qui réduit la probabilité de soumettre des enregistrements incomplets.
Requis statique vs. dynamique
Il existe deux façons de rendre un champ requis dans Odoo. La première est un requis statique : le champ est toujours obligatoire, peu importe quoi. La seconde est un requis dynamique : le champ devient obligatoire uniquement lorsque certaines conditions sont remplies, en fonction des valeurs d'autres champs sur le même enregistrement.
Les deux approches sont régulièrement utilisées dans le développement Odoo. Le choix dépend de votre logique commerciale.
Comment fonctionne le champ
Comprendre comment l'attribut required fonctionne à un niveau technique vous aide à l'appliquer correctement et à déboguer les problèmes lorsqu'ils surviennent.
Application de la contrainte au niveau de l'application
Un détail important qui surprend de nombreux utilisateurs d'Odoo : l'attribut required est appliqué au niveau de l'application, et non au niveau de la base de données. Cela signifie que la contrainte est vérifiée par l'ORM Odoo lorsqu'un enregistrement est créé ou écrit, avant que les données n'atteignent la base de données.
Aucune contrainte NOT NULL n'est ajoutée à la colonne PostgreSQL sous-jacente par défaut lorsque vous définissez required=True sur un champ. La validation se fait en Python, à l'intérieur de la couche ORM d'Odoo.
En pratique, cela signifie que les données insérées directement dans la base de données (en contournant Odoo) ne seront pas prises en compte par la contrainte requise. Interagissez toujours avec les champs de votre base de données Odoo via l'ORM ou l'API pour bénéficier de cette protection.
Que se passe-t-il lorsque la contrainte est violée
Lorsqu'un utilisateur essaie d'enregistrer un formulaire avec un champ requis laissé vide, deux choses se produisent :
- Le champ devient rouge dans l'interface, et Odoo affiche un message de validation
- L'opération d'enregistrement est bloquée jusqu'à ce que le champ soit rempli
Si vous déclenchez la validation de manière programmatique (par exemple, via l'API XML-RPC ou une action serveur), Odoo lève une ValidationError avec un message indiquant quel champ requis est manquant.
Requis dynamique utilisant des domaines
Dans le cadre Odoo, l'attribut required peut être rendu conditionnel en utilisant des expressions au niveau de la vue. Dans Odoo 16 et les versions antérieures, cela se fait avec l'attribut attrs dans le XML de la vue :
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />Dans Odoo 17 et les versions ultérieures, la syntaxe est simplifiée avec une expression required directe sur la balise de champ dans la vue :
<field name="x_delivery_date" required="order_type == 'delivery'" />Ces règles conditionnelles se trouvent dans la couche de vue, pas dans la couche de modèle. C'est une distinction importante : le required=True au niveau du modèle impose toujours la contrainte, tandis que les expressions au niveau de la vue ne s'appliquent que dans des contextes d'interface spécifiques.
Interaction avec l'ORM et l'API
Dans l'ORM d'Odoo, lorsque vous appelez create() ou write() sur un modèle, l'ORM vérifie tous les champs avec required=True avant d'exécuter l'opération de base de données. Si un champ requis est manquant ou défini sur False, Odoo lève une ValidationError.
Cela s'applique également lors de la création d'enregistrements via l'API XML-RPC. Tout champ marqué comme requis dans la définition du modèle doit être fourni dans le dictionnaire de données passé à la méthode create, sinon l'appel échouera avec une erreur.
Cas d'utilisation commerciale
Les champs requis apparaissent dans l'ensemble d'Odoo standard, et ils sont également utiles dans les configurations personnalisées. Voici cinq exemples concrets issus de flux de travail réels où rendre un champ requis fait une réelle différence.
1. CRM : Segment de Client Requis sur les Leads
Une équipe de vente souhaite s'assurer que chaque lead est attribué à un segment de client avant d'être déplacé dans le pipeline. Sans un champ requis, les représentants commerciaux sautent souvent cette étape, rendant impossible le reporting sur les sources de leads par segment par la suite.
En marquant un champ de sélection personnalisé "Segment de Client" comme requis sur le formulaire de lead CRM, l'équipe s'assure que les données sont toujours capturées au moment de l'entrée. Pas de segment, pas d'enregistrement.
2. Ventes : Adresse de Livraison Requise sur les Commandes
Pour les entreprises qui expédient des biens physiques, l'adresse de livraison est critique. Dans certaines configurations Odoo, le champ d'adresse de livraison n'est pas requis par défaut, ce qui signifie que les commandes peuvent être confirmées sans.
Rendre le champ d'adresse de livraison requis sur le formulaire de commande de vente empêche la confirmation de la commande avant que l'équipe logistique ait les informations dont elle a besoin. Cela élimine une source courante d'erreurs dans le processus de réalisation.
3. Inventaire : Numéro de Lot ou de Série Requis à la Réception
Pour les entreprises opérant dans des secteurs réglementés (alimentation, pharmaceutique, électronique), le suivi des numéros de lot sur les biens reçus n'est pas optionnel. Odoo prend en charge cela nativement grâce au paramètre de suivi sur les produits, qui impose effectivement un numéro de lot ou de série requis lors des mouvements de stock.
Pour les champs personnalisés sur les formulaires de réception, comme une référence de contrôle qualité, rendre le champ obligatoire garantit que l'équipe d'entrepôt n'oublie jamais de consigner les informations lors du processus de réception.
4. Comptabilité : Centre de Coût Obligatoire sur les Factures Fournisseurs
Les équipes financières ont souvent besoin que chaque dépense soit affectée à un centre de coût pour le suivi budgétaire. Sans enforcement, les comptables ou les responsables des achats peuvent laisser le champ vide, créant des lacunes dans le reporting financier.
Un champ many2one obligatoire pointant vers le modèle de centre de coût, ajouté au formulaire de facture fournisseur, garantit qu'aucune facture ne peut être publiée sans cette affectation. Ce type de personnalisation Odoo est rapide à mettre en œuvre et a un impact direct sur la complétude des données.
5. RH : Type de Contrat Obligatoire Avant l'Intégration
Les équipes RH gérant l'intégration des employés dans Odoo souhaitent souvent s'assurer que le type de contrat est enregistré avant que le dossier de l'employé ne soit finalisé. Un champ obligatoire sur le formulaire de l'employé empêche l'équipe RH de sauvegarder par inadvertance un dossier d'employé incomplet pendant une période d'intégration chargée.
Créer ou personnaliser le champ
Il existe deux principales façons de marquer un champ comme obligatoire dans Odoo : utiliser Odoo Studio pour une approche sans code, ou écrire du code Python pour un contrôle total. Les deux sont valides selon votre contexte.
Utilisation d'Odoo Studio
Odoo Studio est l'outil intégré sans code qui vous permet de configurer des champs sans aucun développement. Lorsque vous ouvrez Studio et sélectionnez un champ sur un formulaire, vous verrez un bouton "Obligatoire" dans le panneau des propriétés du champ à droite.
Activer ce bouton marque le champ comme obligatoire dans la vue et stocke la contrainte au niveau du modèle. C'est l'approche la plus rapide pour des cas simples et ne nécessite aucune connaissance technique. Elle fonctionne bien pour les champs Odoo standard et les champs personnalisés ajoutés via Odoo Studio.
La limitation de Studio est qu'il ne configure qu'une contrainte obligatoire statique. Pour un comportement obligatoire dynamique basé sur d'autres valeurs de champ, vous devez modifier directement le XML de la vue ou utiliser l'approche technique.
Approche Technique : Champs Python
Dans un module Odoo personnalisé, déclarer un champ requis est aussi simple que d'ajouter required=True à la définition du champ. C'est le modèle standard dans le développement de champs python odoo :
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'PME'),
('enterprise', 'Entreprise'),
('public', 'Secteur Public'),
],
string='Segment Client',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Centre de Coût',
required=True,
)Avec cette approche, la contrainte est appliquée au niveau du modèle, ce qui signifie qu'elle s'applique peu importe la vue ou l'interface utilisée pour créer l'enregistrement. Elle ne peut pas être contournée en accédant à l'enregistrement via une vue différente.
Requis Dynamique dans XML de Vue
Lorsque la contrainte requise ne doit s'appliquer que sous certaines conditions, ajoutez-la au niveau de la vue plutôt qu'au niveau du modèle. Dans Odoo 16 :
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />Dans Odoo 17 :
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />C'est une contrainte uniquement au niveau de la vue. Elle est moins stricte qu'une contrainte requise au niveau du modèle, car elle ne s'applique que lorsque l'enregistrement est modifié via la vue spécifique contenant cette définition.
Création de Champs Requis via l'API
Si vous utilisez l'API XML-RPC pour créer des champs (comme couvert dans d'autres articles de la collection Odoo Data & API), vous pouvez définir required lors de l'appel de create sur ir.model.fields. Cela fait partie du guide de développement standard d'odoo pour la personnalisation programmatique :
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Segment Client',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'PME'), ('enterprise', 'Entreprise')]",
'required': True,
'state': 'manual',
}]
)Cela crée le champ et impose la contrainte requise en une étape, ce qui est utile dans les flux de déploiement automatisés pour les scénarios de création de champs Odoo.
Meilleures pratiques
Marquer un champ comme requis semble simple, mais bien l'utiliser demande réflexion. Voici les pratiques qui vous feront gagner du temps et éviteront la frustration de vos utilisateurs.
1. Ne rendre les champs requis que lorsqu'ils le sont vraiment
Exiger trop de champs est l'une des erreurs de configuration Odoo les plus courantes. Si un utilisateur ne peut pas remplir un formulaire parce qu'un champ est requis mais que l'information n'est pas encore disponible, il trouvera des solutions de contournement (comme entrer des valeurs de remplacement) qui corrompent vos données.
Avant de marquer un champ comme requis, demandez-vous : cette information est-elle toujours disponible au moment de l'entrée ? Si la réponse n'est pas un oui clair, envisagez de le rendre requis à un stade ultérieur (par exemple, à la confirmation plutôt qu'à la création) ou utilisez un requis dynamique à la place.
2. Utilisez la validation basée sur les étapes plutôt que toujours requis
Pour les flux de travail avec plusieurs étapes, comme une opportunité CRM ou un ordre de fabrication, il est souvent préférable d'imposer des champs requis à des étapes spécifiques plutôt que dès le départ. Cela se fait généralement par le biais de contraintes Python ou d'actions automatisées qui vérifient les valeurs des champs lorsque l'enregistrement passe à une étape donnée.
Ce modèle est plus flexible et convivial que de rendre chaque champ requis dès le premier jour.
3. Associez les champs requis avec des valeurs par défaut lorsque cela a du sens
Si un champ est requis et a une valeur par défaut raisonnable dans la plupart des cas, définissez un default dans la définition du champ. Cela réduit les frictions pour les utilisateurs qui n'ont pas besoin de changer la valeur par défaut, tout en garantissant que le champ n'est jamais vide.
4. Préférez les requis au niveau du modèle pour les données critiques
Pour les données qui sont réellement critiques (comme les informations comptables, les identifiants réglementaires ou les identifiants obligatoires), imposez la contrainte au niveau du modèle en Python plutôt qu'au niveau de la vue uniquement. Les contraintes requises au niveau de la vue peuvent être contournées si un enregistrement est créé via l'API ou une autre vue qui n'inclut pas la contrainte.
5. Communiquer les champs requis aux utilisateurs finaux
Lorsque vous ajoutez de nouveaux champs requis à des formulaires existants, les utilisateurs en cours de flux de travail peuvent être surpris. Communiquez les changements à votre équipe avant de déployer, surtout si des enregistrements existants pourraient échouer à la validation lors de la prochaine modification.
6. Tester avec des données vides et partielles
Avant de déployer une configuration avec de nouveaux champs requis, testez toujours le flux de travail complet avec des valeurs vides et des données partielles. Cela inclut les tests via l'interface web, via l'API, et via toutes actions automatisées ou intégrations qui créent des enregistrements dans Odoo. C'est une étape de base dans tout tutoriel technique responsable sur Odoo.
Pièges courants
Même les implémenteurs Odoo expérimentés rencontrent des problèmes avec les champs requis. Savoir quoi surveiller vous fera gagner du temps de débogage et évitera des retours en arrière douloureux.
Piège 1 : Rendre un champ requis sur un modèle qui a déjà des enregistrements
Si vous ajoutez required=True à un champ sur un modèle qui contient déjà des milliers d'enregistrements, et que ces enregistrements n'ont pas de valeur pour ce champ, vous pourriez rencontrer des problèmes lors de la prochaine modification de ces enregistrements. Les utilisateurs ne pourront pas enregistrer de modifications tant qu'ils n'auront pas rempli le champ nouvellement requis.
Avant de déployer une contrainte requise sur un champ existant, vérifiez toujours si les enregistrements existants ont déjà des valeurs. S'ils n'en ont pas, effectuez une migration de données pour peupler le champ d'abord.
Piège 2 : Confondre les champs requis au niveau de la vue et au niveau du modèle
Définir un champ comme requis dans une vue (que ce soit via Studio ou XML de vue) n'impose pas la contrainte au niveau du modèle. Un enregistrement créé via l'API, une vue différente, ou une importation contournera complètement les contraintes requises au niveau de la vue.
Si vous avez besoin d'une contrainte stricte, définissez required=True dans la définition du champ Python. C'est un point souvent mal compris dans la communauté des tutoriels sur les champs Odoo, et cela cause de réels problèmes de qualité des données en production.
Piège 3 : Champs requis dans des actions automatisées ou programmées
Lorsqu'une action automatisée ou une action planifiée crée des enregistrements de manière programmatique, elle doit fournir des valeurs pour tous les champs requis. Si l'action a été écrite avant l'ajout d'un champ requis, elle commencera à échouer silencieusement ou avec une erreur cryptique après le déploiement de la contrainte requise.
Revoyez toujours tout le code de création d'enregistrements automatisés après avoir ajouté un champ requis à un modèle existant.
Piège 4 : Importation de données manquant des champs requis
Lors de l'importation d'enregistrements via CSV ou l'outil d'importation Odoo, les champs requis manquants dans le fichier d'importation entraîneront l'échec de l'importation. C'est en fait le comportement correct, mais cela surprend les utilisateurs qui sont habitués à importer des données partielles.
Incluez toujours tous les champs requis dans vos modèles d'importation. Il est bon de documenter quels champs sont requis dans vos directives d'importation de données.
Piège 5 : Utiliser requis au lieu d'une contrainte Python pour une validation complexe
L'attribut required vérifie uniquement qu'un champ n'est pas vide. Il ne valide pas le contenu ou la relation entre les champs. Pour une validation plus complexe (par exemple, s'assurer qu'une date est dans le futur, ou que deux champs sont cohérents), utilisez un décorateur @api.constrains en Python à la place.
Essayer d'encoder la logique métier uniquement dans des champs requis conduit à des configurations inflexibles qui sont difficiles à maintenir.
Conclusion
L'attribut champ requis est l'un des outils les plus simples dans Odoo, mais il a un impact réel sur la qualité de vos données. Bien utilisé, il garantit que les informations critiques sont toujours capturées au bon moment dans vos processus métier. Mal utilisé, il frustre les utilisateurs et crée des solutions de contournement qui rendent vos données moins fiables, pas plus.
La clé est de comprendre la différence entre les contraintes requises au niveau du modèle et celles au niveau de la vue, d'être délibéré sur les champs qui nécessitent réellement une application, et de réfléchir à l'avance à la manière dont la contrainte se comportera dans les flux de travail automatisés et les intégrations API.
Que vous suiviez un guide de développeur Odoo, que vous réalisiez un projet de personnalisation complet d'Odoo, ou que vous ajustiez simplement un formulaire dans Odoo Studio, l'attribut requis mérite d'être compris en profondeur. C'est l'un de ces détails qui sépare une mise en œuvre Odoo propre d'une mise en œuvre qui cause des maux de tête six mois après la mise en service.
Besoin d'aide avec votre mise en œuvre d'Odoo ?
Chez Dasolo, nous aidons les entreprises à mettre en œuvre, personnaliser et optimiser Odoo à travers toutes les fonctions commerciales et niveaux de complexité. Que vous ayez besoin d'aide pour concevoir un modèle de données solide, configurer des règles de validation ou construire des modules personnalisés, notre équipe apporte à chaque projet une expertise technique et fonctionnelle.
Si vous avez des questions sur les champs requis ou tout autre aspect de votre configuration Odoo, nous sommes heureux de vous aider. Contactez-nous et parlons de ce que vous êtes en train de construire.