Introduction
Chaque fois qu’un utilisateur choisit la priorité d’un lead, sélectionne un mode de paiement ou change l’état d’un produit dans Odoo, il interagit très probablement avec un champ Selection. Ce type de champ est simple en apparence mais central pour conserver une donnée structurée et exploitable dans tous les modules.
Contrairement à un champ texte libre où chacun tape ce qu’il veut, le champ Selection limite les choix à une liste prédéfinie. Cette contrainte est volontaire : elle uniformise les valeurs, facilite les filtres et les rapports, et évite les fautes de frappe ou variantes qui finissent par fausser les tableaux de bord.
Ce guide explique ce que stocke ce champ, comment il s’affiche dans l’interface et comment le créer ou le modifier via Odoo Studio, un module Python ou l’API XML-RPC. Vous y trouverez aussi des exemples concrets métiers et les erreurs à éviter.
Qu’est-ce que le champ Selection dans Odoo
Dans l’ORM d’Odoo, un champ Selection conserve une chaîne correspondant à une option fixe. Chaque option est définie par une paire technique/affichage : la clé est enregistrée en base et l’étiquette est celle présentée à l’utilisateur.
Prenons l’exemple d’un champ « priorité » qui propose plusieurs niveaux :
priority = fields.Selection([
('0', 'Normal'),
('1', 'Low'),
('2', 'High'),
('3', 'Very High'),
], string='Priority', default='0')Ici, '0' à '3' sont les clés sauvées en base. Les libellés Normal, Low, High et Very High sont ce que l’utilisateur voit. Cette séparation permet de modifier l’étiquette visible sans altérer les enregistrements existants.
Dans l’interface, le champ Selection s’affiche comme un menu déroulant dans les vues formulaire et comme un libellé lisible dans les vues en liste. En utilisant le widget badge, chaque option devient une pastille colorée, pratique pour repérer rapidement un statut dans une vue dense.
Dans Odoo Studio, on parle aussi de champ Selection. Les champs créés via Studio reçoivent un préfixe x_studio_. Quand vous le créez en code ou via l’API, vous décidez du nom technique.
Comment fonctionne ce type de champ
Au niveau base de données, les champs Selection sont stockés en PostgreSQL dans une colonne VARCHAR. Seule la clé est persistée, jamais l’étiquette. C’est un point essentiel quand vous écrivez des domaines ou des actions serveur : il faut appeler la valeur par sa clé technique.
Ainsi, pour rechercher tous les leads de haute priorité, le domaine doit être [('priority', '=', '2')] et non [('priority', '=', 'High')].
Attributs clés du champ
Voici les propriétés les plus utiles d’un champ Selection dans Odoo :
- selection : la liste de tuples
(clé, libellé)définissant les choix possibles. Cela peut aussi être le nom d’une méthode (chaîne) retournant dynamiquement la liste. - default : la clé choisie par défaut lorsque aucune valeur n’a été définie. Sans cela, le champ peut rester vide.
- required : contraint l’utilisateur à sélectionner une option avant sauvegarde. Combiné à un défaut, c’est courant pour les champs d’état.
- selection_add : permet, lors d’un héritage de module, d’ajouter des options à un champ Selection existant sans redéfinir toute la liste — c’est la méthode recommandée pour étendre un champ natif.
- ondelete : associé à
selection_add, il précise le comportement des enregistrements qui utilisaient une option ajoutée quand le module ajoutant l’option est désinstallé.
Listes statiques vs dynamiques
Par défaut, les options sont déclarées statiquement. On peut toutefois fournir le nom d’une méthode à l’argument selection : Odoo appellera cette méthode au runtime pour construire la liste, ce qui permet d’afficher des choix différents selon l’utilisateur, la société ou le contexte.
contract_type = fields.Selection(
selection='_get_contract_types',
string='Contract Type'
)
def _get_contract_types(self):
if self.env.user.has_group('hr.group_hr_manager'):
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term'), ('interim', 'Interim')]
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term')]Affichage dans les vues
En formulaire, le Selection est un dropdown standard. Vous pouvez aussi utiliser widget="badge" pour obtenir des étiquettes colorées en liste ou kanban, ou widget="radio" pour afficher des boutons radio inline — utile quand le nombre d’options est faible et qu’on veut toutes les voir d’un coup.
Interaction avec l’ORM d’Odoo
Lire et écrire un champ Selection via l’ORM est direct : on affecte la clé, Odoo gère l’affichage. Via l’API XML-RPC, la méthode fields_get renverra la liste complète de [clé, libellé], pratique pour recréer l’affichage côté outils externes.
Cas d’usage en entreprise
Le champ Selection est omniprésent dans quasiment tous les modules Odoo. Voici cinq exemples concrets issus de workflows métiers courants.
CRM : priorité des leads et types d’étapes
La priorité sur les leads est un Selection natif à quatre niveaux. Les commerciaux l’utilisent pour hiérarchiser l’action. Cette valeur nourrit le code couleur du Kanban et peut déclencher des actions automatiques quand un lead monte en priorité — une des premières optimisations de qualité de données après le déploiement d’un CRM.
Ventes : termes de paiement et politique de facturation
Le champ invoice_policy d’un produit est un Selection qui définit si la facturation se base sur les quantités commandées ou livrées — décision qui influe sur tout le flux de facturation. De la même manière, les abonnements utilisent un Selection pour distinguer prépaiement et postpaiement. Ce sont des exemples où le choix influe sur la logique métier, pas seulement sur l’affichage.
Stock : états qualité des produits et lots
En production et contrôle qualité, les Selection servent à suivre les états des lots, numéros de série ou ordres de réparation. Par exemple, un ordre de réparation traverse « brouillon », « confirmé », « en réparation », « prêt », « terminé ». Chaque transition peut déclencher mails, mouvements de stock ou écritures comptables — le Selection devient alors le pivot du workflow.
Comptabilité : méthode de paiement et type de journal
Le type de journal en compta est un Selection qui distingue ventes, achats, caisse et banque. Odoo s’appuie sur cette valeur pour appliquer la logique d’écriture, limiter les comptes disponibles et restreindre certaines opérations au bon type de journal — un Selection qui dicte des règles métiers, pas juste un label.
RH : type d’emploi et statut de contrat
En RH, les Selection suivent types d’emploi, états des contrats et demandes de congé. Le statut d’un contrat passe par des étapes (nouveau → actif → expiré/annulé). Des automatisations peuvent prévenir le responsable RH avant expiration, lancer des checklists d’intégration ou adapter les règles de paie selon le type d’emploi.
Créer ou personnaliser un champ Selection
Trois manières principales existent pour ajouter un champ Selection à un modèle Odoo, selon que vous voulez du no-code, du versionné ou du programmatique.
Via Odoo Studio (sans code)
Odoo Studio permet d’ajouter un champ sans coder. Pour créer un Selection avec Studio :
- Ouvrez Odoo Studio depuis le menu principal.
- Allez sur le formulaire cible.
- Glissez un champ Selection depuis la barre latérale vers le formulaire.
- Ajoutez vos options dans le panneau de propriétés en renseignant un libellé par choix.
- Définissez éventuellement une valeur par défaut et marquez le champ comme requis.
- Enregistrez et fermez Studio.
Studio génère une clé automatiquement et préfixe le champ par x_studio_. C’est la méthode la plus rapide pour itérer pendant une réunion fonctionnelle avec un client.
Via Python dans un module personnalisé
Pour les développeurs, on déclare les Selection en Python dans les models. C’est la voie recommandée pour les personnalisations versionnées et déployables :
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_delivery_slot = fields.Selection([
('morning', 'Morning (8h - 12h)'),
('afternoon', 'Afternoon (13h - 17h)'),
('evening', 'Evening (18h - 20h)'),
], string='Delivery Slot', default='morning')Après définition, il faut ajouter le champ dans le XML de la vue pour qu’il soit visible. Lors de l’installation ou de la mise à jour du module, Odoo créera automatiquement la colonne en base.
Pour étendre un champ natif, préférez selection_add plutôt que de redéfinir tout le champ :
class SaleOrder(models.Model):
_inherit = 'sale.order'
state = fields.Selection(
selection_add=[('custom_approval', 'Pending Approval')],
ondelete={'custom_approval': 'set default'}
)Via l’API XML-RPC
Si vous gérez des personnalisations de façon automatisée (pipeline, scripts distants), vous pouvez créer des champs Selection via l’API XML-RPC :
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_contract_category',
'field_description': 'Contract Category',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('standard', 'Standard'), ('premium', 'Premium'), ('custom', 'Custom')]",
'state': 'manual',
}]
)Attention : via l’API, la valeur selection doit être fournie comme chaîne représentant la liste Python. L’attribut state: 'manual' indique que le champ a été créé manuellement — approprié pour Studio ou l’API. C’est une méthode souvent utilisée pour automatiser les configurations clients.
Bonnes pratiques
1. Choisir des clés signifiantes et stables
La clé est ce qui reste en base et sert dans les domaines, actions automatiques et règles serveur. Choisissez une clé descriptive et durable. Des chaînes courtes en minuscules comme 'draft', 'confirmed' ou 'cancelled' sont préférables à des numéros qui compliquent la lecture et la maintenance.
2. Garder la liste courte et complète
Dès que la liste dépasse huit–dix options, c’est souvent le signe qu’un champ veut trop en faire. Réfléchissez à une relation Many2one vers un modèle de configuration si les choix évoluent régulièrement : cela permet aux utilisateurs de gérer les options sans intervention développeur.
3. Toujours définir un défaut pour les champs requis
Si le champ est requis, donnez-lui une valeur par défaut raisonnable. Cela évite des erreurs de validation lors d’imports, créations programmatiques ou appels API où l’utilisateur n’est pas présent pour choisir une valeur.
4. Utiliser selection_add pour étendre les champs natifs
Pour ajouter des options à un champ existant dans un module personnalisé, préférez selection_add plutôt que la redéfinition complète. C’est plus sûr et compatible avec d’autres modules. N’oubliez pas d’associer ondelete pour gérer la désinstallation.
5. Employer le widget badge pour la visibilité en liste
En listes et kanbans, le rendu standard est du texte. Ajouter widget="badge" transforme les valeurs en pastilles colorées, ce qui facilite la lecture et la priorisation — particulièrement utile pour les statuts à surveiller.
Pièges fréquents
Changer une clé casse les données existantes
On peut modifier un libellé sans risque puisque seule la clé est stockée. En revanche, changer la clé après que des enregistrements l’utilisent rendra ces enregistrements invalides et interrompra domaines et automatisations. Si une clé doit changer, préparez une migration pour mettre à jour toutes les occurrences en base.
Supprimer une option laisse des enregistrements orphelins
Retirer une option alors que des enregistrements contiennent encore sa clé laissera des valeurs manquantes. Avant de supprimer, identifiez et mettez à jour ou archivez les enregistrements concernés — une erreur fréquente lors de nettoyages de données.
Filtrer par libellé au lieu de la clé
Un piège courant, surtout pour les utilisateurs non techniques, est d’écrire un domaine avec le libellé visible au lieu de la clé technique. Cela retourne zéro résultat sans erreur explicite. Vérifiez toujours la définition du champ pour utiliser la bonne clé dans les filtres et automatisations.
Utiliser un Selection quand un Many2one est préférable
Si les options changent souvent, si les utilisateurs doivent les gérer eux-mêmes, ou si chaque option porte des attributs (couleur, séquence, compte lié), alors un Many2one vers un modèle de configuration est plus adapté. Les Selection conviennent aux listes stables et gérées par le développeur.
Ne pas gérer la valeur vide dans la logique serveur
Un Selection non requis peut valoir False. Si votre code compare directement la valeur à une chaîne sans vérifier le cas vide, vous risquez des comportements inattendus ou des erreurs. Gérez explicitement False dans les actions serveur et champs calculés dépendant du Selection.
Conclusion
Le champ Selection semble simple mais révèle sa complexité quand on examine son fonctionnement interne. Comprendre la différence entre clé et libellé, quand utiliser selection_add ou un Many2one, et anticiper les migrations sont des éléments qui font la différence entre une implémentation Odoo durable et une usine à problèmes.
Que vous ajoutiez un type de contrat via Studio, définissiez une plage de livraison dans un module Python ou créiez un état qualité via l’API, les principes exposés ici vous aident à choisir la solution adaptée à votre situation.
Dans le modèle de données Odoo, le champ Selection est un outil essentiel pour garantir la qualité d’origine des données. Bien utilisé, il maintient vos enregistrements propres, vos rapports fiables et vos automatisations stables.
Chez Dasolo, nous accompagnons les organisations pour implémenter, personnaliser et optimiser Odoo dans tous les services. Que vous ayez besoin d’un modèle de données clair, d’ajouts de champs sur-mesure ou du développement complet d’un module, notre équipe peut vous aider. Contactez-nous et discutons de votre projet Odoo.