Odoo 19 : des dates relatives directement dans vos domaines ORM

Écrire un filtre du type « les commandes des sept derniers jours » a longtemps été plus pénible qu'il ne devrait dans Odoo. Il fallait injecter un calcul Python dans le domaine, avec relativedelta ou context_today(), et espérer que l'évaluation se fasse au bon moment et dans le bon fuseau. La version 19 apporte une réponse à ce problème précis. Le changelog ORM officiel liste une entrée « Adding support for dynamic dates in domains », rattachée à la pull request #216665 ¹.

Le problème que ça règle

Jusqu'ici, une date relative dans un domaine s'exprimait par du code évalué côté serveur ou côté client. La description de la PR le résume sans détour : la valeur était calculée au moment de l'évaluation, avec relativedelta, ce qui devient vite complexe à l'intérieur d'un domaine ². Concrètement, vous écriviez quelque chose comme :

Domain('moment', '>', datetime.now() - relativedelta(minutes=5))

Ce genre d'expression fonctionne, mais elle mélange la logique de requête et un calcul de date. Elle dépend aussi de variables d'environnement comme context_today(), ce qui complique la relecture et le débogage quand un filtre ne renvoie pas ce qu'on attend.

La nouvelle syntaxe

Odoo 19 introduit un petit langage de chaînes pour exprimer ces bornes directement dans le domaine. Les deux exemples fournis par la PR donnent le ton ² :

Domain('moment', '>', 'now -5M')
Domain('moment', '>=', '=monday -1w')

La première ligne remplace exactement l'exemple relativedelta(minutes=5) cité plus haut : now -5M désigne « il y a cinq minutes ». La seconde ancre la borne sur un jour de la semaine, ici le lundi, puis recule d'une semaine avec -1w. La fonctionnalité couvre les champs date comme les champs datetime, et l'ancrage sur un jour nommé (=monday) permet de viser un repère calendaire plutôt qu'un simple décalage.

L'intérêt pratique est double. D'abord, la borne redevient lisible : on lit l'intention dans la chaîne au lieu de reconstituer un calcul. Ensuite, la PR indique que ce mécanisme retire la dépendance à des variables comme context_today() et ajoute un niveau d'optimisation dans l'évaluation des domaines pour gérer les valeurs qui dépendent du contexte ².

Ce que ça touche dans vos modules

Cette syntaxe ne se limite pas à un usage ponctuel dans un search. Un domaine se retrouve dans beaucoup d'endroits : les filtres enregistrés (ir.filters), les domaines par défaut d'actions, les règles d'enregistrement (ir.rule), les champs domain de relations, ou encore les vues. Partout où vous glissiez auparavant un calcul de date, vous disposez désormais d'une option plus courte.

Cela change aussi la façon d'auditer un module lors d'une montée de version. Un domaine à base de chaîne est une donnée, pas du code exécuté. C'est plus sûr côté sécurité, mais la contrepartie est réelle : une faute de frappe dans la chaîne ne se voit pas à l'écriture, et un domaine mal formé échoue à l'exécution, pas à l'installation. Il faut donc tester chaque filtre concerné sur une base 19 avant de considérer la migration terminée.

À vérifier avant de généraliser

Trois précautions me semblent utiles. La première : ne réécrivez pas mécaniquement tous vos anciens domaines, car un calcul relativedelta existant continue de fonctionner et la nouvelle syntaxe reste une addition, pas une obligation. La deuxième : documentez la signification exacte de chaque unité employée dans vos chaînes, car un lecteur qui découvre =monday -1w ne devine pas forcément la convention. La troisième : vérifiez le comportement en présence de fuseaux horaires, puisque l'ancien code s'appuyait justement sur context_today() pour gérer ce point.

Le reste du changelog ORM 19.0 accompagne ce mouvement de nettoyage. La même page acte la dépréciation de odoo.osv et l'ajout du support des GROUPING SETS pour les vues pivot ¹. On retrouve la logique habituelle d'une version majeure, qui ajoute des raccourcis modernes tout en marquant la sortie des anciennes API.

Notre lecture

Cette fonctionnalité ne bouleverse rien dans l'architecture, et c'est précisément sa qualité. Elle attaque un point de friction que tout développeur Odoo a rencontré, sans casser l'existant. Pour un projet en préparation de montée vers la 19, je la traiterais comme une commodité à adopter progressivement : on la déploie sur les nouveaux filtres, on garde les anciens tant qu'ils passent les tests, et on profite de l'occasion pour recenser tous les domaines à base de date d'un module. Le vrai gain tient moins à la brièveté de now -5M qu'à la relecture d'un filtre six mois plus tard, sans avoir à dérouler un calcul de dates dans sa tête.

Sources

• Odoo 19.0 ORM Changelog (dépôt officiel de la documentation) : https://github.com/odoo/documentation/blob/19.0/content/developer/reference/backend/orm/changelog.rst
• Pull request Odoo #216665, « Adding support for dynamic dates in domains » : https://github.com/odoo/odoo/pull/216665