« Qui approuve un achat au-delà de 5 000 € ? » est une question d'organisation, pas de logiciel — jusqu'au jour où il faut l'inscrire dans l'outil. base_tier_validation est le moteur générique qui le permet dans Odoo, sur n'importe quel modèle.
Il faut le dire tout de suite, parce que c'est la source de déception la plus fréquente : ce module ne valide rien tout seul. C'est un socle. Il faut y adjoindre un module d'implémentation, par exemple purchase_tier_validation pour les bons de commande, qui greffe le mécanisme sur le modèle métier.
L'essentiel
- Socle générique : il fournit le moteur, les écrans de configuration et les éléments d'interface. Pas de validation sur un document sans module d'implémentation.
- Trois façons de désigner un réviseur : un utilisateur précis, n'importe quel membre d'un groupe, ou la valeur d'un champ du document.
- Validation séquentielle possible : le palier 10 doit être approuvé avant que le palier 20 ne devienne actionnable.
- Le document est bloqué en écriture pendant la validation — sauf champs explicitement exemptés.
- Compteur de revues en attente dans la barre d'icônes d'Odoo, et rappel automatique programmable en jours.
- Licence AGPL-3, dépôt OCA
server-ux, branche 18.0, dépend demail.
Ce que le module ajoute à l'instance
| Élément | Nombre |
|---|---|
| Modèles créés | 1 |
| Modèles étendus | 6 |
| Champs ajoutés | 101 |
| Menus | 3 |
| Vues | 12 |
| Actions de fenêtre | 2 |
| Groupes de droits | 0 |
Le seul modèle créé est tier.validation.exception. Les six modèles étendus sont comment.wizard, res.config.settings, res.users, tier.definition, tier.review et le modèle abstrait tier.validation — c'est ce dernier qu'un module d'implémentation vient hériter sur son propre modèle métier.
Le mécanisme repose sur trois objets qu'il faut distinguer :
| Objet | Ce qu'il est |
|---|---|
tier.definition | La règle : qui approuve, à quelles conditions, dans quel ordre |
tier.review | La revue : une instance de la règle, créée sur un document donné |
tier.validation.exception | L'exception : les champs qui restent modifiables malgré le blocage |
Chaque revue passe par les statuts Waiting → Pending → Approved / Rejected / Cancel. Un document ne franchit son état cible — brouillon vers confirmé, par exemple — que lorsque toutes les revues requises sont approuvées.
Où le trouver dans Odoo
| Menu | Ce qu'on y fait |
|---|---|
| Paramètres ▸ Technique ▸ Validations par niveau | Le menu racine du module |
| … ▸ Définition de niveau | Créer et gérer les règles de validation |
| … ▸ Tier Validation Exception | Déclarer les champs exemptés du blocage en écriture |
Sur les documents qui utilisent le mécanisme, le module injecte trois éléments d'interface : un bouton Request Validation dans l'en-tête, un bandeau jaune avec les boutons Validate et Reject pour le réviseur concerné, et un tableau de revues qui montre l'état de chaque palier.
Un réglage global facultatif existe dans Paramètres généraux, bloc « Tier Validation » : l'option Tier Formula, qui installe un module complémentaire permettant de déterminer les réviseurs par formule Python.
Cas d'usage
Une règle simple, un réviseur unique
- Paramètres ▸ Technique ▸ Validations par niveau ▸ Définition de niveau, puis Nouveau.
- Description : nommer la règle explicitement, par exemple « Validation manager pour bons de commande > 5 000 € ».
- Referenced Model : choisir le modèle du document — il doit déjà hériter
tier.validation. - Laisser Validated by sur « Specific user » et choisir le Reviewer.
- Onglet Apply On : définir le domaine qui restreint les documents concernés, par exemple un filtre sur le montant total.
- Enregistrer : la règle s'applique immédiatement à tout nouveau document correspondant au domaine.
Le domaine de l'onglet Apply On est le cœur du paramétrage. Sans lui, la règle s'applique à tous les documents du modèle — y compris les commandes de 40 €, ce qui transforme une mesure de contrôle en irritant quotidien.
Validation par groupe, en séquence
Le cas d'une double approbation : un responsable, puis la direction.
- Créer une première définition avec Validated by = « Any user in a specific group », choisir le Reviewer group, cocher Approve by sequence, Sequence = 10.
- Créer une seconde définition sur le même modèle, autre groupe ou réviseur, Approve by sequence cochée, Sequence = 20.
- Sur le document, cliquer sur Request Validation pour générer les revues.
- Le réviseur du palier 10 approuve ; la revue du palier 20 passe alors de Waiting à Pending et devient actionnable.
Exempter des champs du blocage en écriture
Indispensable en pratique : pendant une validation, le document est verrouillé, et il reste souvent un champ qu'il faut pouvoir corriger — une référence interne, une date de livraison souhaitée.
- Paramètres ▸ Technique ▸ Validations par niveau ▸ Tier Validation Exception, puis Nouveau.
- Choisir le Model, puis ajouter les champs à exempter dans Fields.
- Dans Groups, restreindre éventuellement l'exception à certains groupes (vide = tous).
- Cocher Write under Validation et/ou Write after Validation — au moins une des deux est obligatoire.
Relancer automatiquement les revues en attente
- Ouvrir la définition de niveau concernée.
- Onglet More Options, champ Send reminder message on pending reviews : saisir un nombre de jours, par exemple 3.
- Enregistrer : la tâche planifiée « Send Tier Review Reminder », exécutée quotidiennement, prend le relais.
C'est le réglage qui fait la différence entre un circuit de validation et un circuit de blocage. Une revue en attente que personne ne relance arrête le document — et l'utilisateur en conclut que l'outil ne marche pas.
Configuration et droits
- Installer
base_tier_validation, puis au moins un module d'implémentation pour le modèle à contrôler (par exemplepurchase_tier_validation). - Créer les règles dans Définition de niveau, avec un domaine restrictif.
- Déclarer les exceptions d'écriture nécessaires.
- Activer les rappels sur les définitions où l'attente coûte quelque chose.
Les droits sont volontairement serrés, et c'est cohérent avec l'objet du module :
| Action | Groupe requis |
|---|---|
| Créer, modifier, supprimer une définition de niveau | base.group_erp_manager |
| Créer, modifier, supprimer une exception | base.group_system |
| Lire ces deux modèles, gérer les revues | Tout utilisateur interne (base.group_user) |
En multi-sociétés, les définitions et les revues sont filtrées par société (company_id in company_ids + [False]). Une règle sans société s'applique donc à toutes : c'est commode, et c'est un piège si les entités n'ont pas les mêmes seuils d'approbation.
Limites connues
Le dépôt répertorie un défaut qui mérite d'être connu avant de choisir la validation séquentielle.
- Compteur du systray et
approve_sequence: le champcan_reviewdetier.review, qui filtre les notifications de la barre d'icônes, est mis à jour en base par la méthodereview_user_count. Sur une base avec beaucoup d'utilisateurs et des mises à jour fréquentes, cela peut rendre le compteur incohérent. - Migration : à partir de la 15.0, le paramètre
_tier_validation_manual_configpasse àFalse; en 14.0 sa valeur par défaut étaitTrue. Le changement s'applique après migration, et il faut modifier la valeur sur le modèle concerné pour obtenir le nouveau comportement.
Deux limites d'usage, observées et non répertoriées :
- Un domaine trop large transforme le contrôle en frein. Commencez par un seuil élevé, puis descendez-le si nécessaire — l'inverse se vit mal.
- Un palier sans suppléant bloque tout pendant les congés du réviseur. Le mode « Any user in a specific group » est presque toujours préférable à « Specific user ».
Identité technique
| Nom technique | base_tier_validation |
| Dépôt OCA | server-ux, branche 18.0 |
| Version du module | 18.0.3.5.1 |
| Licence | AGPL-3 |
| Dépendances | mail |
| Modules d'implémentation | purchase_tier_validation, et d'autres selon le modèle à contrôler |
| Version Odoo | 18.0 Community |
Un conseil de mise en service, tiré de l'expérience : un seul niveau d'approbation au démarrage. Trois niveaux conçus le premier jour sont contournés dès la première urgence. Voir les sept erreurs d'un projet ERP.
Questions fréquentes
Pourquoi rien ne se passe après l'installation du module ?
C'est le comportement normal, et la déception la plus fréquente : base_tier_validation est un socle qui ne s'active sur aucun document métier par lui-même. Il faut installer un module d'implémentation — purchase_tier_validation pour les bons de commande, par exemple — qui hérite le mixin tier.validation sur le modèle concerné.
Peut-on exiger deux approbations dans un ordre précis ?
Oui : créez deux définitions de niveau sur le même modèle, cochez Approve by sequence sur les deux et donnez-leur des séquences différentes (10, puis 20). La revue de séquence 20 reste en Waiting jusqu'à l'approbation de celle de séquence 10.
Le document est-il modifiable pendant la validation ?
Non, il est bloqué en écriture — c'est le principe. Les champs qui doivent rester modifiables se déclarent dans une Tier Validation Exception, avec le choix d'appliquer l'exception pendant la validation, après, ou les deux.
Comment éviter qu'une absence bloque tout le circuit ?
En choisissant Validated by = « Any user in a specific group » plutôt qu'un utilisateur précis : n'importe quel membre du groupe peut alors approuver. C'est la configuration que nous recommandons par défaut, pour cette seule raison.
Les réviseurs sont-ils notifiés ?
Oui, par e-mail et dans le chatter à chaque étape — création, mise en attente, acceptation, rejet, redémarrage — et un compteur de revues en attente apparaît dans la barre d'icônes d'Odoo. Un rappel automatique se règle en jours sur chaque définition de niveau.
Pour aller plus loin
- account_payment_order : ordres de paiement groupés
- auditlog : savoir qui a modifié quoi dans Odoo
- Les droits utilisateurs dans Odoo : qui voit quoi
En résumé
base_tier_validation est un moteur d'approbation générique, pas une fonctionnalité prête à l'emploi : il lui faut un module d'implémentation. Une fois en place, trois réglages décident de son succès — un domaine restrictif, un groupe plutôt qu'un utilisateur, et un rappel automatique. Parlons de vos circuits d'approbation.
