Introducción
En Odoo, los modelos determinan la forma y el lugar donde se guarda la información. Cada elemento de datos empresariales —artículos, contactos, pedidos— vive dentro de un modelo concreto y ahí es donde Odoo lo gestiona y lo recupera.
Los modelos forman la columna vertebral de la arquitectura de datos en Odoo. Definen los campos, las relaciones entre registros y la lógica de negocio asociada. Tanto los consultores funcionales como los desarrolladores deben comprender su funcionamiento para configurar, extender y depurar el sistema con eficacia.
Aquí nos centramos en el modelo blog.post, la pieza que sustenta la funcionalidad de blog en los sitios web de Odoo. Ya sea que publiques desde la interfaz, sincronices entradas mediante API o personalices el comportamiento del blog, acabarás interactuando con este modelo.
¿Qué es el modelo blog.post?
El modelo blog.post representa una entrada individual de blog. Cada registro equivale a un artículo que puede mostrarse en tu web y que contiene título, cuerpo, metadatos y estado de publicación.
Este modelo forma parte del módulo website_blog y funciona en conjunto con otros modelos: blog.blog actúa como contenedor del blog y blog.tag organiza las etiquetas. Crear o editar un artículo desde la interfaz genera cambios en registros blog.post.
blog.post hereda comportamientos de varios mixins: por ejemplo, mail.thread para el chatter y website.published.mixin para la lógica de publicación. Conocer estas herencias es clave a la hora de ampliarlo o modificar su comportamiento.
No es un modelo transitorio ni abstracto: blog.post es un modelo persistente. Las entradas se almacenan en la base de datos y son accesibles vía API para consultas, actualizaciones o sincronizaciones.
Campos clave del modelo
A continuación se describen los campos más relevantes del modelo blog.post. Conocerlos te permitirá manipular correctamente el contenido del blog desde la interfaz, los módulos o las integraciones.
1. name
Tipo: Char. Guarda el título de la entrada. Es obligatorio y se muestra en listados, formularios y en la web. También suele aparecer en la pestaña del navegador y en los resultados de búsqueda, por lo que influye en la experiencia de lectura y en la visibilidad.
2. blog_id
Tipo: Many2one (blog.blog). Vincula la entrada con su blog contenedor. Cada post pertenece a un único blog, lo cual te permite segregar contenidos en secciones como Noticias, Actualizaciones de producto o Guías técnicas y facilitar la navegación.
3. subtitle
Tipo: Char. Subtítulo breve o tagline que acompaña al título en la página del artículo y algunos listados. Es útil para mejorar la legibilidad y aportar una línea adicional optimizada para buscadores.
4. content
Tipo: Html. Contenido principal del artículo. Acepta HTML enriquecido, imágenes y fragmentos de Odoo Website. Es el campo donde se almacena el cuerpo del post que verán los visitantes.
5. teaser
Tipo: Text. Texto de previsualización generado automáticamente a partir del contenido. Es de solo lectura y sirve para mostrar un avance en listados o tarjetas de blog.
6. teaser_manual
Tipo: Text. Resumen manual que sustituye al teaser automático cuando se rellena. Ideal para control editorial cuando el primer párrafo no resume bien el artículo.
7. author_id
Tipo: Many2one (res.partner). Enlace al autor del artículo, que puede ser un contacto o un usuario. Se muestra en la entrada y en los listados, útil para blogs con varios autores y control de atribuciones.
8. author_name
Tipo: Char. Nombre visible del autor calculado a partir de author_id. Campo de solo lectura usado para mostrar la etiqueta del autor sin necesidad de consultar la relación completa.
9. author_avatar
Tipo: Binary. Imagen de avatar del autor que acompaña al nombre en la página del post. Opcional, pero aporta reconocimiento visual y confianza al lector.
10. is_published
Tipo: Boolean. Indica si la entrada está publicada y es visible en la web. Es un campo calculado de solo lectura; la publicación real se controla desde website_published.
11. website_published
Tipo: Boolean. Campo editable para publicar o dejar en borrador una entrada. True para que sea visible, False para mantenerla en estado borrador. Es la palanca que maneja is_published.
12. post_date
Tipo: Datetime. Fecha que se muestra como fecha de publicación al visitante. Sirve para ordenar entradas y planificar contenido; puede apuntar al futuro para programar publicaciones.
13. published_date
Tipo: Datetime. Fecha real en la que la entrada pasó a estar publicada. Se rellena automáticamente cuando website_published cambia a True y resulta útil para métricas y análisis temporales.
14. active
Tipo: Boolean. Indicador de archivo lógico. Cuando es False, la entrada queda archivada y no aparece en vistas por defecto; no se borra físicamente para conservar el historial.
15. tag_ids
Tipo: Many2many (blog.tag). Conjunto de etiquetas asociadas a la entrada. Permiten filtrar y agrupar contenido por temas; las etiquetas pueden organizarse por categorías si necesitas jerarquía.
16. visits
Tipo: Integer. Contador de visitas. Solo lectura y se incrementa al visualizar la entrada. Es útil para identificar contenido popular y tomar decisiones editoriales basadas en datos.
17. website_url
Tipo: Char. Ruta completa hacia la entrada en la web. Solo lectura. Su formato habitual combina el slug del blog y del post: /blog/{blog-seo-name}-{blog-id}/{post-seo-name}-{post-id}.
18. cover_properties
Tipo: Text. Cadena JSON que guarda propiedades de la imagen de portada: posición, overlay y ajustes de visualización que usa el frontend para renderizarla correctamente.
19. header_visible
Tipo: Boolean. Indica si se muestra el encabezado del sitio en la página del post. Útil cuando quieres entradas a ancho completo o integradas en otras páginas sin el header habitual.
20. footer_visible
Tipo: Boolean. Control de visibilidad del pie de página en la entrada. Suele complementarse con header_visible para diseños inmersivos o landing pages.
21. seo_name
Tipo: Char. Slug amigable para SEO que define la parte de la URL del post. Se genera automáticamente desde name si no se especifica; mejor fijarlo en entradas importantes y evitar caracteres problemáticos.
22. website_meta_title
Tipo: Char. Título meta para buscadores. Aparece en la pestaña del navegador y en resultados de búsqueda; es un elemento clave en la optimización SEO on-page.
23. website_meta_description
Tipo: Text. Descripción meta que los motores muestran en snippets. Se recomienda redactarla con 150–160 caracteres para maximizar su impacto en las SERP.
24. website_meta_keywords
Tipo: Char. Palabras clave meta; tienen menos peso hoy en día, pero pueden ser útiles para ciertos sistemas o integraciones heredadas.
25. create_date
Tipo: Datetime. Fecha de creación del registro en la base de datos. Odoo la gestiona automáticamente y sirve para informes y auditoría.
26. create_uid
Tipo: Many2one (res.users). Usuario que creó el registro. Campo automático y de solo lectura, útil para trazabilidad.
27. write_date
Tipo: Datetime. Fecha de la última modificación. Se mantiene automáticamente y ayuda a saber cuándo se actualizó el contenido por última vez.
28. write_uid
Tipo: Many2one (res.users). Usuario que realizó la última modificación. Campo de solo lectura que facilita auditoría y control de cambios.
29. display_name
Tipo: Char. Nombre mostrado calculado que se utiliza en desplegables Many2one y resultados de búsqueda. Es de solo lectura y facilita la identificación rápida del registro.
30. website_id
Tipo: Many2one (website). En entornos con varias webs, indica a qué sitio pertenece la entrada. Si se deja vacío, la entrada puede mostrarse en todos los sitios según la configuración.
Cómo se emplea este modelo en los flujos de trabajo empresariales
1. Marketing de contenidos y SEO
Los equipos de marketing crean registros blog.post para publicar artículos y optimizarlos para buscadores. Trabajan los campos website_meta_title, website_meta_description y seo_name para mejorar la visibilidad, usan content para el cuerpo del artículo y organizan los temas mediante tag_ids.
2. Sitios con varios blogs
Empresas suelen tener varios blogs (Noticias, Novedades, Documentación técnica). Cada blog.blog agrupa múltiples blog.post; el campo blog_id establece esa pertenencia y permite que los visitantes naveguen por secciones y apliquen filtros por etiquetas.
3. Contenido impulsado por API
Integraciones externas crean y sincronizan blog.post vía XML-RPC o JSON-RPC: migraciones desde otro CMS, sincronización con soluciones headless o generación automática desde sistemas internos. El modelo está expuesto por la API para operaciones CRUD y búsquedas.
4. Publicación programada
Programando post_date en el futuro y marcando website_published, puedes dejar entradas listas para publicarse en la fecha prevista. Es ideal para calendarios editoriales y campañas temporizadas.
5. Colaboración y autoría múltiple
El campo author_id combinado con mail.thread facilita el trabajo colaborativo: se asignan autores, los seguidores reciben notificaciones y el chatter permite comentarios internos antes de lanzar la publicación.
Cómo amplían los desarrolladores este modelo
Los desarrolladores amplían blog.post mediante varios patrones, siendo la herencia de modelos en Odoo la vía habitual para añadir campos, lógica o personalizaciones de comportamiento.
Herencia de modelos
Declara _inherit = 'blog.post' en tu módulo para extender el modelo. Puedes añadir nuevos campos, sobreescribir métodos o añadir restricciones. Mantener tus cambios en un módulo separado facilita actualizaciones. Ten en cuenta las herencias existentes (mail.thread, website.published.mixin) al modificar métodos relacionados.
Añadir campos
Define nuevos campos con el tipo adecuado: Char, Many2one, Boolean, Integer, Text o Selection. Para metadatos personalizados (por ejemplo, tiempo de lectura o categorías internas) añade campos y publícalos en las vistas. Usa el prefijo x_ para minimizar conflictos con futuras versiones de Odoo.
Extensiones en Python
Sobrescribe create, write o unlink para añadir lógica en el servidor, y llama a super() para no romper comportamientos previos. Ten cuidado con campos controlados por mixes como website_published y post_date; si necesitas rutas URL personalizadas, considera sobreescribir _compute_website_url correctamente.
Odoo Studio
Odoo Studio permite añadir campos sin tocar código y es útil para cambios rápidos. Para lógica compleja, integraciones o vistas personalizadas, los módulos mantienen la trazabilidad y la mantenibilidad. Recuerda que el modelo blog.post está accesible vía XML-RPC y JSON-RPC para integraciones.
Buenas prácticas
- Rellenar website_meta_title y website_meta_description en cada entrada mejora la visibilidad SEO y controlas cómo se presenta tu contenido en buscadores.
- Usa teaser_manual cuando el resumen automático no refleje el mensaje principal. Los teasers personalizados suelen convertir mejor en listados y redes sociales.
- Fija seo_name en las entradas clave para controlar la URL y evitar caracteres que puedan romper rutas o afectar al SEO.
- En integraciones API, publica mediante website_published; no intentes escribir directamente en is_published porque es de solo lectura y no aplicará la lógica esperada.
- Organiza la taxonomía con tag_ids: crea y reutiliza etiquetas consistentes para facilitar búsquedas, filtros y recomendaciones de contenido.
Errores frecuentes
- Error: escribir en is_published en lugar de website_published. is_published es calculado y no acepta escritura directa; siempre usa website_published para cambiar el estado de publicación.
- Error: olvidar asignar blog_id. Es un campo necesario para que la entrada se muestre correctamente dentro de un blog; sin él la visibilidad y la navegación pueden fallar.
- Error: dejar website_meta_description vacío. Los motores pueden elegir fragmentos aleatorios de la página para el snippet; proporciona siempre una descripción clara y optimizada de 150–160 caracteres.
- Error: sobrescribir métodos clave sin llamar a super(). Eso puede desactivar funcionalidades del mixin de publicación o del chatter y causar comportamientos inesperados.
- Error: duplicar seo_name dentro del mismo blog. Las URLs pueden entrar en conflicto; deja que Odoo genere slugs únicos o implementa tu propia lógica de unicidad.
Conclusión
El modelo blog.post es la pieza central del blog en Odoo: almacena artículos, contenido, metadatos y el estado de publicación. Comprender sus campos y cómo se relaciona con blog.blog y blog.tag facilita su configuración, personalización e integración.
Tanto si eres consultor funcional que gestiona el contenido como desarrollador que crea integraciones, dominar blog.post reduce tiempo de implementación y evita errores comunes.
¿Necesitas ayuda con tu implementación de Odoo?
Dasolo acompaña a las empresas en la implementación, personalización y optimización de Odoo. Contamos con experiencia práctica en integraciones por API y en el diseño de módulos alineados con la arquitectura de datos de Odoo, incluidos modelos como blog.post.
Si necesitas apoyo con tu implementación de Odoo, desarrollo de módulos o integraciones, podemos ayudarte a planificar y ejecutar la solución. Solicita una demo para hablar de tu proyecto.