« Il ne faut jamais valider un devis sans adresse de livraison. » « Pas de commande d'achat à ce fournisseur au-delà de 10 000 € sans visa. » Ces règles existent dans toutes les entreprises ; elles vivent dans la tête de deux personnes et se perdent à leur départ.
base_exception permet de les écrire dans l'outil. Comme base_tier_validation, c'est un socle : il fournit le moteur et les écrans, et il n'a aucun effet métier sans un module d'implémentation — sale_exception pour les devis, purchase_exception pour les achats.
Résumé
Le module permet d'inscrire dans Odoo les règles métier qui vivent aujourd'hui dans la tête de deux personnes — un champ obligatoire, un seuil, une incohérence — et de bloquer ou signaler un document avant validation.
Comme base_tier_validation, c'est un socle sans effet seul : il lui faut un module d'implémentation. Et le dépôt signale lui-même que le code Python des règles passe par safe_eval, avec un risque de sécurité non résolu — d'où deux consignes : mode By domain par défaut, et groupe réservé aux administrateurs.
L'essentiel
- Trois modes de détection : par domaine Odoo, par code Python, ou par appel à une méthode existante du modèle.
- Bloquant ou non : une case Is Blocking décide si l'utilisateur peut passer outre.
- Une fenêtre de confirmation récapitule les exceptions en cours avant de poursuivre l'action.
- Aucun effet seul : sans module d'implémentation, les listes de modèles et de méthodes sont vides.
- Risque de sécurité signalé par le dépôt : le code Python des règles est exécuté via
safe_eval. - Un groupe dédié : « Exception manager », à ne pas distribuer largement.
Ce que le module ajoute à l'instance
| Élément | Nombre |
|---|---|
| Modèles créés | 3 |
| Modèles étendus | 1 |
| Champs ajoutés | 23 |
| Menus | 1 |
| Vues | 3 |
| Actions de fenêtre | 2 |
| Groupes de droits | 1 |
Le modèle central est exception.rule : une règle, rattachée à un modèle Odoo, avec son mode de détection et son caractère bloquant ou non. À côté, le modèle abstrait base.exception est celui qu'un module d'implémentation vient hériter sur un modèle réel.
C'est cette architecture en deux pièces qui explique le comportement du module installé seul : l'écran de création de règles existe, mais la liste Apply on est vide, parce qu'aucun modèle ne s'est enregistré.
Où le trouver dans Odoo
| Menu | Accessible à |
|---|---|
| Paramètres ▸ Technique ▸ Règles de restriction | Membres du groupe « Exception manager » uniquement |
Un seul menu, et c'est volontaire : ce module s'adresse aux personnes qui définissent les règles, pas à celles qui les subissent. Les utilisateurs, eux, rencontrent le module sous la forme d'une fenêtre de confirmation au moment de valider un document.
Le groupe technique est base_exception.group_exception_rule_manager. Les utilisateurs du groupe de base (base.group_user) n'ont qu'un droit de lecture sur les règles.
Cas d'usage
Une règle par domaine : le cas le plus sûr
C'est le mode à privilégier, parce qu'il n'exécute aucun code : la règle est un filtre Odoo, construit avec le sélecteur graphique.
- Paramètres ▸ Technique ▸ Règles de restriction, puis Nouveau.
- Renseigner Exception Name et Description — la description est ce que l'utilisateur lira dans la fenêtre de confirmation, elle doit être explicite.
- Choisir le modèle cible dans Apply on (la liste dépend des modules d'implémentation installés).
- Sélectionner By domain dans les boutons radio de type.
- Renseigner le domaine, avec le sélecteur graphique : il doit correspondre aux enregistrements à signaler ou bloquer.
- Cocher Is Blocking si l'exception ne doit jamais pouvoir être ignorée.
- Enregistrer.
Le point d'attention sur le domaine : il décrit les documents en faute, pas les documents conformes. Une règle inversée bloque exactement l'inverse de ce qu'on voulait, et c'est l'erreur la plus fréquente à la première règle.
Bloquant ou simple alerte : l'arbitrage qui compte
La case Is Blocking est le seul réglage réellement structurant du module.
| Non bloquante | Bloquante | |
|---|---|---|
| Ce que voit l'utilisateur | Une fenêtre récapitulative, puis il peut continuer | Une fenêtre, et il ne peut pas continuer |
| Quand la choisir | Règle d'hygiène, information utile | Exigence légale, risque financier |
| Effet sur l'adoption | Acceptée | Contournée si elle est injustifiée |
La dernière ligne est le conseil qui compte : une règle bloquante que l'équipe juge arbitraire finit contournée — par un autre chemin, un autre journal, un autre document. Réservez le blocage à ce qui le mérite vraiment, et laissez le reste en alerte.
Les modes code Python et méthode
Les deux autres modes existent pour les cas qu'un domaine ne peut pas exprimer : une règle qui compare deux champs, qui compte des lignes, ou qui appelle une logique déjà écrite dans le modèle.
- By python code : une expression évaluée sur l'enregistrement. Puissant, et c'est exactement ce qui porte le risque de sécurité décrit plus bas.
- By method : l'appel d'une méthode existante du modèle. Plus sûr, mais il faut que la méthode existe — donc un développement en amont.
Le risque de sécurité, signalé par le dépôt
C'est la limite la plus importante de ce module, et elle est écrite noir sur blanc dans sa propre documentation : le code Python saisi dans une règle est exécuté via safe_eval, ce qui peut représenter un risque de sécurité. Le dépôt indique que la façon d'atténuer ce risque reste à traiter dans de futures versions.
Conséquence pratique, et elle n'est pas négociable :
- N'attribuez le groupe « Exception manager » qu'à des administrateurs. Créer une règle en mode Python équivaut à faire exécuter du code sur votre instance.
- Privilégiez systématiquement le mode « By domain », qui n'exécute rien. La grande majorité des règles métier s'expriment par un domaine.
- Relisez les règles existantes si plusieurs personnes ont eu ce groupe par le passé.
C'est aussi un argument en faveur du mode « By method » quand un domaine ne suffit pas : la logique vit alors dans un module versionné et relu, pas dans un champ texte de la base. Voir les droits utilisateurs dans Odoo et les six mesures de sécurité qui comptent.
Configuration
- Installer
base_exception— il ne dépend que debase_setup. - Installer un module d'implémentation :
sale_exception(dépôtsale-workflow) pour les devis,purchase_exception(dépôtpurchase-workflow) pour les achats. Sans cela, les listes Apply on et method restent vides. - Attribuer le groupe
base_exception.group_exception_rule_managerà un ou deux administrateurs — pas plus. - Créer les règles, en commençant par le mode By domain et en non bloquant.
- Après deux ou trois semaines d'observation, passer en bloquant celles qui le méritent.
L'étape 5 est la méthode qui fait adopter ce module : on observe d'abord combien de documents une règle attraperait, on ajuste le domaine, puis on bloque. Bloquer d'emblée sur une règle non éprouvée produit un arrêt de production et une mauvaise réputation pour l'outil.
Limites connues
Le dépôt répertorie une limite, et c'est celle qui doit guider le déploiement.
- « Ce module exécute du code fourni par l'utilisateur via un
safe_eval, ce qui peut être non sécurisé. La façon d'atténuer ce risque devrait être traitée dans de futures versions. » C'est la formulation du dépôt lui-même.
Trois limites d'usage s'y ajoutent :
- Aucun effet sans module d'implémentation. C'est la même architecture que
base_tier_validation, et la même déception à l'installation. - Le domaine décrit les documents en faute, pas les conformes. Une règle inversée bloque exactement l'inverse de l'intention.
- Une règle bloquante injustifiée se contourne. Le module ne protège pas contre un autre chemin de saisie ; il protège une action précise sur un modèle précis.
Si votre besoin est une approbation par une personne plutôt qu'un contrôle sur des données, c'est l'autre module qu'il faut : base_tier_validation. Les deux se complètent — l'un vérifie le contenu, l'autre demande un visa.
Identité technique
| Nom technique | base_exception |
| Dépôt OCA | server-tools, branche 18.0 |
| Version du module | 18.0.1.3.0 |
| Licence | AGPL-3 |
| Dépendances | base_setup |
| Modules d'implémentation | sale_exception, purchase_exception |
| Groupe créé | Exception manager (group_exception_rule_manager) |
Il fait partie de notre socle commun, installé mais sans règle active : les règles se définissent avec le client, parce qu'elles décrivent son organisation.
Questions fréquentes
Pourquoi la liste « Apply on » est-elle vide ?
Parce qu'aucun module d'implémentation n'est installé. base_exception est un socle : il fournit le moteur et les écrans, et il faut un module comme sale_exception ou purchase_exception qui hérite le mixin base.exception sur un modèle réel pour que celui-ci apparaisse dans la liste.
Quelle différence avec base_tier_validation ?
base_exception vérifie le contenu d'un document — un champ manquant, un montant hors limite — et bloque ou signale. base_tier_validation demande un visa à une personne. Les deux se complètent : l'un contrôle les données, l'autre organise l'approbation.
Le mode code Python est-il dangereux ?
Le dépôt le signale lui-même : le code des règles est exécuté via safe_eval, ce qui peut représenter un risque de sécurité, et la façon d'atténuer ce risque reste à traiter. Conclusion pratique : n'attribuez le groupe « Exception manager » qu'à des administrateurs, et privilégiez le mode « By domain », qui n'exécute rien.
Faut-il rendre les règles bloquantes ?
Pas d'emblée. Commencez en non bloquant, observez deux ou trois semaines combien de documents la règle attrape, ajustez le domaine, puis bloquez ce qui le mérite. Une règle bloquante que l'équipe juge arbitraire finit contournée par un autre chemin de saisie.
Le domaine décrit-il les documents conformes ou en faute ?
Les documents en faute : ceux que la règle doit signaler ou bloquer. C'est l'erreur la plus fréquente à la première règle, et elle produit exactement l'inverse de l'effet voulu — testez toujours sur quelques documents avant d'activer le blocage.
Se faire accompagner
Ce module demande deux choses que l'outil ne fournit pas : des règles écrites — donc une organisation explicitée — et un module d'implémentation si le modèle que vous voulez contrôler n'en a pas.
Nous menons l'exercice en deux temps : recueillir les règles qui vivent aujourd'hui dans la tête de vos équipes, puis les écrire en domaines plutôt qu'en code. Et nous développons le module d'implémentation quand il manque — voir les prestations d'Atalios Consulting et notre méthode. Demander un rappel.
Pour aller plus loin
- base_tier_validation : des circuits de validation
- Le socle commun : les 57 modules de chaque instance
- Les droits utilisateurs dans Odoo : qui voit quoi
En résumé
base_exception permet d'inscrire dans Odoo les règles qui vivent aujourd'hui dans la tête de deux personnes. Trois recommandations : un module d'implémentation d'abord, le mode « By domain » toujours quand c'est possible, et le groupe « Exception manager » réservé aux administrateurs — le dépôt signale lui-même le risque du mode Python. Parlons de vos règles métier.
