Odoo 19 : plus de fallback kanban-box, la card devient obligatoire

Si vous maintenez des modules Odoo avec des vues kanban personnalisées, la migration vers la version 19 réserve une mauvaise surprise à ceux qui l'avaient laissée passer en 18. Le template kanban-box, présent dans le framework depuis des années, ne dispose plus d'aucun filet de sécurité. Une vue qui reposait encore dessus ne s'affiche pas : elle lève une erreur au rendu.

Le rename qui date de 18, la suppression qui arrive en 19

Le changement de fond a eu lieu en Odoo 18. Le template racine d'une carte kanban, historiquement déclaré avec <t t-name="kanban-box">, a été remplacé par <t t-name="card">. Dans le code officiel, les vues standard ont toutes basculé à ce moment. Par exemple, la vue des commandes de vente déclare désormais <t t-name="card" class="row g-0 ps-0 pe-0"> ¹.

La différence entre 18 et 19 ne tient pas au rename lui-même, mais à la façon dont le framework traite les vues restées à l'ancienne syntaxe. En Odoo 18, le parseur d'architecture kanban conservait une constante dédiée, LEGACY_KANBAN_BOX_ATTRIBUTE, et un chemin de repli. Si votre vue ne définissait pas de template card, il récupérait le template kanban-box, affichait un avertissement dans la console ('kanban-box' is deprecated, define a 'card' template instead) et continuait de rendre la carte ². Votre module fonctionnait, avec une simple ligne jaune dans les outils de développement du navigateur.

En Odoo 19, ce repli a disparu. Le fichier kanban_arch_parser.js ne connaît plus qu'une seule constante, KANBAN_CARD_ATTRIBUTE = "card". Quand le template card est absent, il ne cherche pas d'alternative : il lève directement Missing 'card' template. ³. La recherche de LEGACY_KANBAN_BOX_ATTRIBUTE dans la version 19 ne renvoie plus aucune occurrence. Le filet a été retiré, pas juste déprécié une seconde fois.

Une structure de carte plus sémantique

Le passage à card ne se limite pas à renommer un attribut. La structure interne a été revue autour de balises HTML porteuses de sens. Les cartes standard s'organisent maintenant avec <header>, <main> et <footer>, là où l'ancien modèle empilait des div avec des classes comme o_kanban_record_top et o_kanban_record_bottom. La vue kanban des tâches de projet en Odoo 19 illustre ce découpage, avec un <main> conditionné à l'état de l'enregistrement et un <footer> masqué en mode sélection ⁴.

Pour un module custom, cela veut dire que le simple remplacement de la chaîne kanban-box par card suffit à faire repartir le rendu, mais ne garantit pas une carte cohérente visuellement. Les classes CSS et la disposition attendues ont changé. Un rendu qui ne casse plus peut tout de même paraître désaligné par rapport aux vues natives voisines.

Ce que ça implique concrètement

Le point sensible tient à la nature silencieuse du problème en amont. Une équipe qui a migré de 17 vers 18 sans lire les journaux de la console a pu conserver des vues à l'ancienne syntaxe sans jamais s'en rendre compte, puisque tout s'affichait. Le saut vers 19 transforme cet avertissement ignoré en panne visible pour l'utilisateur final.

Quelques réflexes utiles avant de lancer une montée de version :

• Rechercher t-name="kanban-box" dans l'ensemble de vos dépôts d'addons, y compris les modules tiers récupérés sur des versions anciennes.
• Vérifier les vues kanban héritées par xpath, où la racine peut être définie ailleurs que dans le module que vous inspectez.
• Tester chaque vue kanban custom sur une base 19 de préproduction, et pas seulement les modèles les plus utilisés.
• Ne pas se contenter du remplacement de nom : contrôler le rendu réel de la carte par rapport aux vues standard.

Ce type de rupture rejoint la logique des autres chantiers de portage front-end, où le coût ne vient pas d'un gros bloc à réécrire mais de la dispersion des points à corriger. Nous l'avions détaillé pour le JavaScript client dans notre article sur le coût réel d'une migration de modules JavaScript custom.

Notre lecture

La suppression du repli kanban-box suit une trajectoire déjà vue ailleurs dans Odoo : une dépréciation en douceur sur une version, puis un retrait net à la suivante. La leçon de terrain est moins technique qu'organisationnelle. Les avertissements de console émis en Odoo 18 étaient exactement le signal à traiter, au moment où la correction restait triviale. Reportée à la migration 19, la même correction devient un incident de production, avec un utilisateur devant une vue qui refuse de s'ouvrir.

Pour les PME et ETI qui pilotent leurs montées de version au rythme d'un intégrateur, la recommandation tient en une phrase : demandez explicitement le relevé des dépréciations remontées par le framework à chaque palier, et traitez-les à ce palier. Une dépréciation non traitée n'est pas un détail cosmétique. C'est une panne différée dont la date d'échéance est la prochaine version majeure.

Sources

• Odoo 19 source, kanban_arch_parser.js (branche 19.0) : https://github.com/odoo/odoo/blob/19.0/addons/web/static/src/views/kanban/kanban_arch_parser.js
• Odoo 18 source, kanban_arch_parser.js (branche 18.0) : https://github.com/odoo/odoo/blob/18.0/addons/web/static/src/views/kanban/kanban_arch_parser.js
• Odoo 19 source, vue kanban des commandes de vente : https://github.com/odoo/odoo/blob/19.0/addons/sale/views/sale_order_views.xml
• Odoo 19 source, vue kanban des tâches de projet : https://github.com/odoo/odoo/blob/19.0/addons/project/views/project_task_views.xml
• Odoo 19 documentation, View architectures : https://www.odoo.com/documentation/19.0/developer/reference/user_interface/view_architectures.html