J'ai travaillé de nombreuses années sur une version 8 qui au fil des ans, l'héritage classique au sens Odoo, nous a amené à avoir un res.partner avec des centaines de champs avec une compréhension du modèle qui devient difficile et dont la migration devient très complexe. Aujourd'hui, nous repensons le modèle pour justement éviter l'héritage classique d'Odoo (en Odoo 17) et, à peu de chose près, le code que l'on voit plus haut correspond à ce qu'il faudrait faire. Le codeur à l'origine a certainement voulu faire une conception Objet afin de pouvoir typer les modèles et de ne pas polluer d'innombrables datas dans la seule table res.partner.
On peut évidemment le faire et cela reste la solution la plus évidente dans un premier temps (faire un _inherit simple), mais on le paye quelques années plus tard.
Dans une conception plus élaborée, on utilise l'abstraction tout en faisant un _inherits (par exemple sur res.partner). Ensuite on construit des modèles spécialisés qui héritent de la classe abstraite. Ainsi, on ne vient pas polluer le modèle res.partner et on peut créer des modèles qui spécialisent des caractéristiques particulières d'une personne. Elle peut être VIP, Manager, et tout ce que l'on veut. Les données sont alors stockées dans des tables distinctes (res.partner.vip, ...) sans à avoir à embarquer tous les champs du modèles res.partner. C'est bien plus propre et réutilisable à souhait.
On perd un peu de temps à mettre en place tout ceci dans un premier temps, mais le gain devient significatif par la suite.
Je ne pense donc pas que ce soit une mauvaise utilisation de l'héritage, par contre Ok avec Nasser sur le reste, on ne réinvente pas la roue, on regarde d'abord s'il n'existe pas des modules qui font le taf. Notamment sur OCA, qui sont généralement très bien faits
Veuillez-vous connecter poster un commentaire
🌍 Travaillez avec des experts basés en Afrique
💵 Tarifs abordables et flexibles
🔍 Experts certifiés
🌟 Assistance personnalisée
🤝 Collaboration exceptionnelle