Introduction
Dans Odoo, chaque type de donnée métier repose sur un modèle : c'est la fiche technique qui décrit quelles informations sont conservées et comment elles s'articulent en base. Toute donnée que vous manipulez — client, produit, facture ou article de blog — vit dans un modèle.
Les modèles forment l'ossature de l'architecture des données d'Odoo. Ils déclarent les champs, les liens entre enregistrements et la logique métier associée. Maîtriser leur fonctionnement est indispensable pour les consultants fonctionnels comme pour les développeurs.
Ici, nous nous intéressons au modèle blog.post. C'est lui qui pilote la gestion des articles sur les sites Odoo : création via l'interface, publication programmée, synchronisation par API ou personnalisation côté backend et frontend passent par ce modèle.
Qu'est-ce que le modèle blog.post
Le blog.post représente un article unique : chaque enregistrement correspond à une fiche d'article qui sera affichée dans votre blog sur le site web.
Ce modèle appartient au module website_blog et fonctionne de pair avec d'autres modèles : blog.blog pour le contenant (le blog lui‑même) et blog.tag pour la classification. Quand vous ajoutez ou modifiez un article depuis l'interface, vous manipulez un enregistrement blog.post.
Le modèle hérite de plusieurs mixins Odoo : par exemple mail.thread pour la fonctionnalité de chatter et followers, et website.published.mixin pour la logique de publication. Comprendre ces héritages est utile lorsque vous voulez étendre ou modifier le comportement natif.
Contrairement à certains modèles temporaires, blog.post est un modèle persistant : ses enregistrements sont stockés en base et accessibles via l'API pour lecture, modification ou suppression logique.
Champs principaux du modèle
Voici les champs clés à connaître dans blog.post : ils couvrent le contenu, le référencement, la publication et la gestion des métadonnées. Les maîtriser facilite l'édition, le filtrage et l'intégration des articles.
1. name
Type : Char. Sert de titre de l'article. Champ obligatoire, visible dans les listes, les formulaires et sur le site. Le nom apparaît aussi dans l'onglet du navigateur et influence les résultats de recherche sur le site.
2. blog_id
Type : Many2one (blog.blog). Lie l'article à son blog parent. Chaque blog.post appartient à un unique blog — pratique pour segmenter le contenu (Actualités, Produits, Guides techniques).
3. subtitle
Type : Char. Petite accroche sous le titre. Affichée sur la page article et parfois dans les aperçus. Utile pour l'expérience lecteur et le référencement.
4. content
Type : Html. Corps principal de l'article, pouvant contenir texte enrichi, images et blocs Odoo. C'est le champ qui contient le contenu visible sur le site.
5. teaser
Type : Text. Extrait généré automatiquement à partir du contenu pour les listes d'articles. Champ calculé et en lecture seule.
6. teaser_manual
Type : Text. Permet de remplacer l'extrait automatique par un résumé personnalisé à afficher dans les listes.
7. author_id
Type : Many2one (res.partner). Relation vers l'auteur (contact ou utilisateur). Affiché sur la fiche article et utile pour les blogs multi‑auteurs.
8. author_name
Type : Char. Nom affiché de l'auteur, calculé à partir de author_id quand présent. Champ en lecture seule.
9. author_avatar
Type : Binary. Image de l'auteur (avatar). Optionnel, utilisé pour améliorer la mise en page des pages auteur.
10. is_published
Type : Boolean. Indique si l'article est publié tel qu'affiché au visiteur. Champ calculé en lecture seule, dérivé du paramètre éditable website_published.
11. website_published
Type : Boolean. Champ modifiable pour publier ou mettre en brouillon un article. True = visible en ligne, False = brouillon. C'est le champ à manipuler pour changer l'état de publication.
12. post_date
Type : Datetime. Date de publication affichée aux visiteurs ; utilisée pour trier les articles. Peut être planifiée dans le futur pour une publication différée.
13. published_date
Type : Datetime. Date réelle de mise en ligne, renseignée automatiquement quand website_published passe à True. Utile pour les rapports et analyses.
14. active
Type : Boolean. Drapeau d'archivage (soft delete). Si False, l'article est masqué des vues par défaut sans être supprimé définitivement.
15. tag_ids
Type : Many2many (blog.tag). Étiquettes de catégorisation pour filtrer et regrouper les articles ; les tags peuvent être organisés en catégories si nécessaire.
16. visits
Type : Integer. Compteur de visites en lecture seule, incrémenté lors des consultations publiques pour suivre la popularité des articles.
17. website_url
Type : Char. Chemin complet vers l'article sur le site. Champ en lecture seule avec un format standard qui inclut le blog et l'ID de l'article.
18. cover_properties
Type : Text. Chaîne JSON décrivant les propriétés de la couverture (positionnement, overlay, taille) utilisée par le frontend pour afficher l'image de tête de l'article.
19. header_visible
Type : Boolean. Contrôle l'affichage de l'en-tête du site sur la page article — pratique pour des mises en page en pleine largeur ou embarquées.
20. footer_visible
Type : Boolean. Contrôle l'affichage du pied de page ; souvent utilisé en conjonction avec header_visible.
21. seo_name
Type : Char. Slug SEO utilisé dans l'URL. Généré automatiquement depuis le titre si laissé vide ; mieux vaut fixer manuellement les articles importants en évitant les caractères problématiques.
22. website_meta_title
Type : Char. Titre SEO affiché dans l'onglet du navigateur et les résultats de recherche — crucial pour le référencement.
23. website_meta_description
Type : Text. Méta description pour les moteurs ; elle apparaît dans les extraits de recherche. Idéalement 150–160 caractères pour un affichage optimal.
24. website_meta_keywords
Type : Char. Mots‑clés méta — moins déterminants aujourd'hui mais parfois encore utilisés par certains outils.
25. create_date
Type : Datetime. Date de création de l'enregistrement, gérée automatiquement par Odoo — utile pour les audits et rapports.
26. create_uid
Type : Many2one (res.users). Utilisateur qui a créé l'article ; renseigné automatiquement.
27. write_date
Type : Datetime. Date de la dernière modification, tenue à jour automatiquement.
28. write_uid
Type : Many2one (res.users). Utilisateur ayant effectué la dernière modification.
29. display_name
Type : Char. Nom affiché calculé, utilisé dans les menus déroulants et recherches — en lecture seule.
30. website_id
Type : Many2one (website). Dans les environnements multi‑sites, indique à quel site appartient l'article ; si vide, l'article peut apparaître sur plusieurs sites.
Comment ce modèle s'intègre dans les processus métier
1. Content Marketing et SEO
Les équipes marketing créent des enregistrements blog.post pour publier des articles optimisés : they remplissent website_meta_title, website_meta_description et seo_name pour le référencement, placent le contenu dans content et utilisent les tags pour organiser les sujets.
2. Sites avec plusieurs blogs
Certaines organisations gèrent plusieurs blogs (Actualités, Mises à jour produit, Documentation). Chaque blog.blog contient ses blog.post ; blog_id permet de rattacher un article à une section précise pour faciliter la navigation et le filtrage.
3. Contenu piloté par API
Des intégrations peuvent créer et synchroniser des blog.post via XML‑RPC ou JSON‑RPC : import depuis un CMS, synchronisation d'un blog headless ou génération automatique depuis des systèmes internes. Le modèle est exposé via l'API pour create/read/update/search.
4. Publication programmée
Pour planifier une mise en ligne, programmez post_date dans le futur et activez website_published. Odoo s'assure que l'article devient visible à la date prévue — pratique pour calendriers éditoriaux.
5. Collaboration et multi‑auteurs
Grâce à author_id et au mixin mail.thread, plusieurs contributeurs peuvent travailler ensemble : affectation d'auteurs, notifications pour les followers et échanges internes via le chatter avant publication.
Comment les développeurs étendent ce modèle
Les développeurs étendent blog.post avec plusieurs approches, l'héritage de modèle restant la technique la plus courante.
Héritage de modèle
Déclarez _inherit = 'blog.post' pour enrichir le modèle : ajouter des champs, surcharger des méthodes ou définir des contraintes. Cela permet d'encapsuler vos changements dans un module séparé et faciliter les mises à jour. Prenez en compte les mixins propriétaires (mail.thread, website.published.mixin) quand vous overridez du comportement.
Ajout de champs
Déclarez de nouveaux champs dans votre modèle hérité en choisissant le bon type (Char, Many2one, Boolean, Integer, Text, Selection). Pour des métadonnées personnalisées (temps de lecture, catégories internes), exposez ces champs dans les vues. Utilisez le préfixe x_ pour éviter les collisions avec les champs standard.
Extensions Python
Surchargez create, write ou unlink pour insérer de la logique métier — n'oubliez pas d'appeler super() pour préserver le comportement natif. Faites attention aux champs calculés par le mixin de publication et, si nécessaire, redéfinissez _compute_website_url pour une logique d'URL spécifique.
Odoo Studio
Odoo Studio offre une voie sans code pour ajouter rapidement des champs et personnaliser les vues — pratique pour des ajustements rapides. Pour des règles métier complexes, des intégrations API ou une maintenance pérenne, préférez un module personnalisé.
Bonnes pratiques
- Remplissez systématiquement website_meta_title et website_meta_description : ce sont des leviers SEO directs pour améliorer la visibilité de chaque article.
- Privilégiez teaser_manual quand l'extrait automatique n'est pas pertinent : un résumé soigné convertit mieux dans les listes et partages sociaux.
- Définissez seo_name pour vos contenus stratégiques et évitez les caractères problématiques afin d'obtenir des URL propres et stables.
- Pour les intégrations API, pilotez la publication via website_published : ne tentez pas de modifier is_published qui est en lecture seule.
- Standardisez l'utilisation des tags via tag_ids : créez et réutilisez des tags préexistants pour maintenir une catégorisation cohérente.
Erreurs fréquentes
- Écrire dans is_published au lieu de website_published. is_published est en lecture seule — utilisez website_published pour publier ou dépublier.
- Oublier de renseigner blog_id. Ce champ est essentiel : un article sans blog associé ne s'affichera pas correctement.
- Laisser website_meta_description vide. Les moteurs peuvent alors extraire un extrait aléatoire de la page. Rédigez une description claire de 150–160 caractères.
- Surcharger les méthodes cœur sans appeler
super(). Cela peut casser le comportement des mixins (publication, chatter). Toujours préserver l'appel à la logique d'origine. - Créer des seo_name dupliqués au sein d'un même blog. Les URL risquent d'entrer en conflit : laissez Odoo générer les slugs ou veillez à leur unicité.
Conclusion
Le modèle blog.post est le pivot du blog sur Odoo : il centralise le contenu, les métadonnées et l'état de publication. Comprendre ses champs et ses relations avec blog.blog et blog.tag facilite la configuration, la personnalisation et les intégrations.
Que vous gériez le contenu au quotidien ou développiez des intégrations techniques, bien connaître blog.post évite des erreurs courantes et accélère le déploiement.
Besoin d'aide pour votre déploiement Odoo ?
Dasolo accompagne les entreprises dans la mise en œuvre, la personnalisation et l'optimisation d'Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une solide expertise sur l'architecture des modèles comme blog.post.
Si vous avez besoin d'aide pour votre implémentation Odoo, la création de modules sur mesure ou des intégrations, notre équipe peut vous accompagner. Réservez une démo pour discuter de votre projet.