Introduction
Si, en remplissant un formulaire Odoo, un champ s’est mis à clignoter en rouge au moment d’enregistrer, vous avez déjà croisé le mécanisme du champ obligatoire. C’est un levier simple mais puissant pour éviter les fiches incomplètes dans vos processus métiers.
Que vous mettiez en place Odoo pour une équipe commerciale, construisiez un modèle spécifique ou développiez un module technique, maîtriser l’attribut required vous évitera bien des erreurs et facilitera la maintenance.
Ce guide explique le comportement du champ dans le framework Odoo, comment le configurer (via Odoo Studio ou en Python), quand l’utiliser et quelles erreurs éviter.
Qu’est-ce qu’un champ obligatoire dans Odoo
Dans Odoo, l’attribut required s’applique au niveau d’un champ et empêche l’enregistrement d’un enregistrement tant que le champ n’a pas de valeur. Il concerne presque tous les types de champs : texte, numérique, sélection, many2one, dates, etc.
C’est un élément central du modèle de données Odoo et l’un des paramètres les plus courants lors des personnalisations. Définir un champ comme obligatoire est souvent la première barrière contre les données incomplètes ou incohérentes.
Apparence dans l’interface
Dans l’interface, les champs obligatoires sont signalés visuellement : en édition, un indicateur s’affiche et, si l’utilisateur tente d’enregistrer sans valeur, Odoo entoure le champ en couleur et affiche un message d’erreur explicite.
Ce retour immédiat dans l’UI aide les utilisateurs à corriger leurs saisies sur le moment et diminue les enregistrements incomplets.
Obligatoire statique vs dynamique
Il existe deux manières de rendre un champ obligatoire : statique — le champ est toujours requis — ou dynamique — le champ devient requis seulement si certaines conditions sont remplies en fonction d’autres champs du même enregistrement.
Les deux méthodes sont couramment utilisées ; le choix dépend directement de votre logique métier et du moment où l’information doit être captée.
Comment ce champ fonctionne
Comprendre le fonctionnement technique de required vous aidera à l’appliquer correctement et à diagnostiquer les problèmes.
Validation au niveau de l’application
Point important souvent méconnu : required est appliqué au niveau de l’application, pas forcément au niveau de la base de données. C’est l’ORM Odoo qui vérifie la contrainte lors d’un create() ou write(), avant d’envoyer les données à PostgreSQL.
Par défaut, Odoo n’ajoute pas automatiquement un NOT NULL au champ PostgreSQL lorsque vous mettez required=True sur un field. La vérification s’effectue en Python, dans la couche ORM d’Odoo.
Concrètement, si quelqu’un injecte des données directement dans la base en contournant Odoo, la contrainte required ne sera pas appliquée. Passez toujours par l’ORM ou les API d’Odoo pour garantir l’intégrité des données.
Que se passe-t-il quand la contrainte est violée
Lorsque l’utilisateur tente d’enregistrer un formulaire avec un champ obligatoire vide, deux choses se produisent :
- l’interface met en évidence le champ et affiche un message d’alerte
- l’opération d’enregistrement est bloquée tant que le champ n’est pas complété
De façon similaire, si la validation est déclenchée par code (XML-RPC, server action…), Odoo lève une ValidationError précisant quel champ obligatoire manque.
Obligatoire dynamique via des domains/expressions
Dans Odoo, on peut rendre required conditionnel via des expressions au niveau de la vue. Jusqu’à Odoo 16 on utilisait principalement l’attribut attrs dans le XML de la vue,
par exemple : <field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />
Depuis Odoo 17, la syntaxe a été simplifiée et permet une expression required directement sur le tag field,
par exemple : <field name="x_delivery_date" required="order_type == 'delivery'" />
Ces règles conditionnelles vivent dans la couche vue, pas dans le modèle : required=True au niveau modèle reste plus strict, tandis que les expressions côté vue ne s’appliquent que dans le contexte de la vue concernée.
Interaction avec l’ORM et les API
Au niveau de l’ORM, create() et write() vérifient les champs déclarés required=True avant d’exécuter l’opération en base. Si un champ requis est absent ou False, Odoo lève une ValidationError.
Cela vaut aussi pour la création via XML-RPC : tout champ requis défini dans le modèle doit être présent dans le dictionnaire de données passé à create, sinon l’appel échoue.
Cas d’usage en entreprise
Les champs obligatoires sont présents dans tout Odoo standard et restent précieux en configuration sur-mesure. Voici cinq cas concrets où obliger un champ change vraiment la qualité des données.
1. CRM : segment client obligatoire sur les leads
Une équipe commerciale veut catégoriser chaque lead par segment pour pouvoir analyser les performances par marché. Sans contrainte, les commerciaux ont tendance à ignorer le champ, rendant les rapports inexacts.
En rendant obligatoire un champ de sélection « Segment client » sur le formulaire de lead, on s’assure que l’information est saisie dès la création : pas de segment, pas d’enregistrement finalisé.
2. Ventes : adresse de livraison obligatoire sur les commandes
Pour les entreprises qui expédient des produits, l’adresse de livraison est incontournable. Dans certaines configurations, ce champ peut rester vide et une commande est tout de même confirmée, générant des blocages logistiques.
Rendre l’adresse de livraison obligatoire sur le bon de commande empêche la confirmation tant que la logistique ne dispose pas des informations nécessaires, éliminant ainsi un risque fréquent d’erreur de fulfillment.
3. Stock : numéro de lot ou série obligatoire à la réception
Dans les secteurs réglementés (alimentaire, pharmaceutique, électronique), tracer les lots à la réception est indispensable. Odoo gère cela via le paramétrage de suivi produit, qui impose de renseigner lot/numéro de série lors des mouvements.
Pour des champs personnalisés sur les réceptions, comme une référence contrôle qualité, rendre le champ obligatoire garantit que l’équipe entre systématiquement cette donnée au moment de la réception.
4. Comptabilité : centre de coût obligatoire sur les factures fournisseurs
Les finances ont souvent besoin d’imputer chaque dépense à un centre de coût pour suivre les budgets. Sans contrainte, des factures peuvent être postées sans imputation, créant des trous dans le reporting.
Un many2one requis vers le modèle des centres analytiques sur le formulaire de facture fournisseur empêche la validation sans imputation, une personnalisation simple qui améliore la complétude des données.
5. RH : type de contrat requis avant onboarding
Pour l’onboarding, les équipes RH veulent parfois que le type de contrat soit défini avant de finaliser le dossier employé. Un champ requis sur le formulaire évite d’oublier cette information pendant les périodes d’activité intense.
Créer ou personnaliser un champ obligatoire
Deux approches principales existent pour rendre un champ obligatoire : la configuration no-code via Odoo Studio, ou la définition en Python pour un contrôle total. Le choix dépend du contexte et de la criticité.
Odoo Studio
Odoo Studio permet, sans coder, d’activer un basculeur « Obligatoire » dans les propriétés du champ lorsque vous éditez un formulaire. C’est rapide et accessible aux administrateurs fonctionnels.
Activer l’option marque le champ comme requis dans la vue et stocke la contrainte côté modèle. C’est la méthode la plus simple pour des cas statiques et pour des champs ajoutés via Studio.
La limitation de Studio : il configure surtout un required statique au niveau vue. Pour des obligations conditionnelles complexes, il faudra modifier le XML de la vue ou opter pour l’approche technique.
Approche technique : champs en Python
Dans un module personnalisé, il suffit d’ajouter required=True à la définition du champ en Python. C’est la méthode standard pour les développements Odoo et elle offre une contrainte appliquée au niveau modèle.
Exemple d’usage en Python : from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)
Avec cette approche, la contrainte s’applique au modèle : peu importe l’interface utilisée pour créer ou modifier l’enregistrement, le champ restera requis et ne pourra pas être contourné.
Required dynamique dans le XML de vue
Quand l’obligation ne doit s’appliquer que dans certains cas, définissez-la côté vue plutôt que modèle. En Odoo 16, on utilisait attrs,
par exemple : <field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />
En Odoo 17, la syntaxe devient plus expressive,
par exemple : <field name="x_cost_center_id"
required="order_type == 'invoiced'" />
Rappel : il s’agit d’une contrainte propre à la vue. Elle est moins contraignante qu’un required au niveau modèle car elle ne s’applique que si l’utilisateur passe par la vue contenant la règle.
Créer des champs requis via l’API
Il est aussi possible de créer des champs et définir required via l’API XML-RPC en appelant ir.model.fields. Utile pour les déploiements automatisés ou les scripts d’installation.
Exemple d’appel XML-RPC : models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)
Cela crée le champ et applique la contrainte required en une seule opération, pratique pour des installations reproductibles.
Bonnes pratiques
Rendre un champ obligatoire paraît simple, mais mal pensé cela génère des frictions. Voici des règles pratiques pour éviter des problèmes à l’usage.
1. N’obligez que ce qui est réellement nécessaire
Trop de champs obligatoires est une erreur fréquente : si l’information n’est pas toujours disponible, les utilisateurs entreront des valeurs factices pour contourner la validation, ce qui dégrade la qualité des données.
Avant d’ajouter required, demandez-vous si la donnée est systématiquement disponible à la saisie. Si ce n’est pas le cas, pensez à la rendre obligatoire plus tard dans le workflow (par ex. à la confirmation) ou à utiliser un required conditionnel.
2. Privilégiez la validation par étape plutôt que l’obligation systématique
Pour les processus en plusieurs étapes, il est souvent préférable de valider certains champs à des étapes spécifiques (ex. passage d’un statut) plutôt que d’imposer tout dès la création. On le fait via des contraintes Python ou des actions automatisées qui vérifient les champs lors d’un changement d’état.
Ce pattern est plus souple et mieux accepté par les utilisateurs que d’exiger tous les champs dès l’origine.
3. Associez des valeurs par défaut quand c’est pertinent
Si un champ requis a une valeur par défaut raisonnable, définissez-la pour réduire la friction. L’utilisateur n’aura généralement rien à modifier, tout en garantissant que le champ n’est jamais vide.
4. Préférez required au modèle pour les données critiques
Pour des informations cruciales (identifiants réglementaires, données comptables…), appliquez required au niveau modèle en Python, car les contraintes côté vue peuvent être contournées via API ou vues alternatives.
5. Informez les utilisateurs des nouveaux champs obligatoires
Quand vous ajoutez des champs requis à des formulaires existants, prévenez les équipes ; des utilisateurs en cours de processus risquent d’échouer lors de la prochaine modification si l’on n’a pas communiqué les changements.
6. Testez avec des jeux de données vides et partiels
Avant mise en production, testez toujours les scénarios avec données manquantes et partielles : interface web, API, et toutes actions automatisées qui créent des enregistrements. C’est un passage obligé pour éviter les surprises.
Pièges fréquents
Même des implémenteurs Odoo expérimentés rencontrent des difficultés avec les champs requis. Voici les problèmes récurrents à surveiller pour gagner du temps en debug.
Piège 1 : rendre un champ obligatoire sur un modèle déjà rempli
Si vous ajoutez required=True sur un champ d’un modèle qui contient déjà des milliers d’enregistrements vides pour ce champ, vous bloquerez les sauvegardes futures jusqu’à ce que ces enregistrements soient complétés.
Avant d’imposer la contrainte sur un champ existant, vérifiez les données en base et, si nécessaire, lancez une migration pour remplir le champ préalable.
Piège 2 : confondre required côté vue et côté modèle
Un required configuré dans une vue (Studio ou XML) n’impose pas la contrainte au niveau modèle : un enregistrement créé par l’API, une autre vue ou une importation contournera la règle.
Si vous avez besoin d’une contrainte solide, mettez required=True en Python dans la définition du champ. C’est une confusion fréquente qui provoque des problèmes de qualité en production.
Piège 3 : champs obligatoires et actions automatisées
Quand un automated action ou planificateur crée des enregistrements, il doit fournir toutes les valeurs requises. Une action écrite avant l’ajout d’un required nouvellement déployé va commencer à échouer.
Passez en revue les scripts et actions automatisées après avoir ajouté un champ requis sur un modèle existant.
Piège 4 : importer des données manquantes
Lors d’une importation CSV, l’absence de champs requis dans le fichier provoquera l’échec de l’import. C’est le comportement attendu, mais cela surprend parfois les utilisateurs qui importent des jeux partiels.
Incluez toujours les champs requis dans vos modèles d’import et documentez clairement quelles colonnes sont indispensables.
Piège 5 : utiliser required pour de la validation complexe
required ne fait que vérifier la présence d’une valeur. Il n’évalue pas la logique métier ni les relations entre champs. Pour des validations plus poussées (date future, cohérence entre deux champs…), utilisez @api.constrains en Python.
Vouloir tout faire avec des champs requis mène à une configuration rigide et difficile à maintenir.
Conclusion
Le champ obligatoire est un outil simple mais déterminant pour la qualité des données dans Odoo. Bien utilisé, il garantit la capture des informations critiques au bon moment ; mal utilisé, il pousse les utilisateurs à recourir à des astuces qui polluent les données.
L’essentiel est de distinguer clairement la portée des contraintes côté modèle et côté vue, de réfléchir aux besoins métier réels, et d’anticiper l’impact sur les integrations et automatisations.
Qu’il s’agisse d’un guide pour développeurs Odoo, d’un projet de personnalisation complet ou d’un réglage dans Odoo Studio, comprendre required fait la différence entre une implémentation propre et une qui posera problème quelques mois plus tard.
Besoin d’aide pour votre implémentation Odoo ?
Chez Dasolo, nous accompagnons les entreprises pour implémenter, personnaliser et optimiser Odoo, quel que soit le niveau de complexité. Nous aidons à concevoir un modèle de données robuste, à paramétrer des règles de validation et à développer des modules sur-mesure.
Si vous avez des questions sur les champs obligatoires ou tout autre aspect de votre instance Odoo, nous pouvons vous accompagner. Contactez-nous et discutons de votre projet.