Introdução
No Odoo, os modelos são as plantas do jardim de dados: definem que informação existe, como se relaciona e onde fica guardada na base de dados. Tudo o que a sua empresa gere — artigos, contactos, encomendas — assenta num modelo.
Os modelos formam a espinha dorsal da arquitetura de dados do Odoo. É neles que se definem campos, ligações entre registos e regras de negócio. Tanto consultores funcionais como programadores precisam de dominar estes conceitos para evitar surpresas ao configurar ou estender o sistema.
Vamos focar-nos no modelo blog.post, que alimenta a funcionalidade de blog nos sites construídos com Odoo. Quer esteja a escrever artigos pela interface, a carregar conteúdos via API ou a adaptar a experiência do leitor, vai interagir com este modelo.
O que é o modelo blog.post
O blog.post representa um único artigo de blog no Odoo: cada registo corresponde a um post que é mostrado no website.
Este modelo faz parte do módulo website_blog e funciona em conjunto com blog.blog (o próprio blog/coleção de posts) e blog.tag (as etiquetas). Sempre que cria ou edita um artigo no backend do Odoo, está a criar ou a modificar um registo blog.post.
O modelo reutiliza funcionalidades através de mixins: por exemplo, integra mail.thread para o histórico e notificações e website.published.mixin para a lógica de publicação. Conhecer estas heranças é essencial quando for preciso estender ou alterar comportamentos.
blog.post é um modelo persistente (não é abstracto nem transitório). Os posts ficam gravados na base de dados e podem ser consultados e manipulados via API.
Campos principais do modelo
A seguir estão os campos mais relevantes do blog.post. Compreendê-los facilita gerir conteúdo, SEO e fluxos de publicação.
1. name
Tipo: Char. Título do artigo — obrigatório. É exibido em listas, formulários e na página do post; aparece também no separador do navegador e nos resultados de pesquisa, por isso afeta a experiência do utilizador e o SEO.
2. blog_id
Tipo: Many2one (blog.blog). Associa o post ao blog a que pertence. É através deste campo que organiza conteúdos em secções (por exemplo Notícias, Lançamentos, Guias).
3. subtitle
Tipo: Char. Uma frase curta ou subtítulo que aparece abaixo do título. Útil para melhorar a leitura e fornecer contexto rápido aos visitantes.
4. content
Tipo: Html. Corpo principal do artigo. Permite conteúdo rico — texto formatado, imagens e blocos do website — e é o campo onde se aloja a maior parte do conteúdo editorial.
5. teaser
Tipo: Text. Excerto gerado automaticamente a partir do conteúdo. Serve para pré-visualizações nas listagens; é um campo calculado e só de leitura.
6. teaser_manual
Tipo: Text. Excerto manual que substitui o teaser automático quando definido. Ideal para resumos personalizados e mais direcionados para conversão ou SEO.
7. author_id
Tipo: Many2one (res.partner). Ligação ao autor do artigo — pode ser um contacto ou um utilizador. Permite gerir blogs com vários autores e mostrar autoria nos posts.
8. author_name
Tipo: Char. Nome de exibição do autor, calculado a partir de author_id quando aplicável. Campo apenas para leitura.
9. author_avatar
Tipo: Binary. Imagem do autor exibida junto ao nome. Opcional, mas útil para humanizar conteúdos em blogs multi‑autor.
10. is_published
Tipo: Boolean. Indica se o post está publicado no website. Campo calculado e apenas para leitura; o controlo efetivo faz‑se através de website_published.
11. website_published
Tipo: Boolean. Campo editável para publicar ou despublicar um post. True = visível no site; False = rascunho. Este campo é o que deve ser usado para alterar o estado público do artigo.
12. post_date
Tipo: Datetime. Data de publicação apresentada aos visitantes. Serve também para ordenar conteúdos e pode ser definida no futuro para agendar publicações.
13. published_date
Tipo: Datetime. Data real em que o post ficou público. É preenchida automaticamente quando website_published passa a True e é útil para relatórios e análise histórica.
14. active
Tipo: Boolean. Sinal de arquivamento (soft delete). Quando falso, o registo fica escondido nas vistas padrão, mas conserva‑se na base de dados para auditoria.
15. tag_ids
Tipo: Many2many (blog.tag). Etiquetas para classificar o conteúdo. Facilitam filtragem e agrupamento; as tags podem também ter categorias para uma organização hierárquica.
16. visits
Tipo: Integer. Contador de visualizações — só leitura. Incrementa quando visitantes acedem ao post e é utilizado para métricas de popularidade.
17. website_url
Tipo: Char. Caminho completo para o artigo no site (somente leitura). Habitualmente segue o padrão /blog/{blog‑seo}/{post‑seo} e é usado pelo frontend para links e partilhas.
18. cover_properties
Tipo: Text. JSON com propriedades da imagem de capa (posição, sobreposição, etc.). Utilizado pelo tema para controlar a aparência do cabeçalho do post.
19. header_visible
Tipo: Boolean. Controla se o cabeçalho do site aparece na página do post — útil para artigos em layouts de largura total ou incorporados.
20. footer_visible
Tipo: Boolean. Controla a visibilidade do rodapé na página do post; geralmente usado em conjunto com header_visible.
21. seo_name
Tipo: Char. Slug amigável para SEO que determina a URL do post. É gerado automaticamente a partir do título se não for preenchido; convém evitar caracteres especiais.
22. website_meta_title
Tipo: Char. Meta title para motores de busca — visível no separador do navegador e nos resultados de pesquisa. Importante para CTR e SEO on‑page.
23. website_meta_description
Tipo: Text. Meta description exibida nos snippets de pesquisa. Recomenda‑se um resumo claro entre 150–160 caracteres para melhor apresentação nos motores de busca.
24. website_meta_keywords
Tipo: Char. Palavras‑chave meta — relevância reduzida hoje em dia, mas pode ser usada por alguns sistemas legados.
25. create_date
Tipo: Datetime. Data de criação do registo, preenchida automaticamente pelo Odoo; útil para reporting e auditoria.
26. create_uid
Tipo: Many2one (res.users). Utilizador que criou o registo — definido automaticamente e apenas leitura.
27. write_date
Tipo: Datetime. Data da última modificação — gerida automaticamente; ajuda a perceber quando o conteúdo foi atualizado pela última vez.
28. write_uid
Tipo: Many2one (res.users). Utilizador que fez a última alteração — campo só leitura e útil para rastreio de alterações.
29. display_name
Tipo: Char. Nome de exibição calculado; aparece em menus de seleção e pesquisas. Só leitura.
30. website_id
Tipo: Many2one (website). Em instalações com vários websites, indica a que site o post pertence. Se vazio, o post pode ser exibido em todas as instâncias do website.
Como este modelo entra nos fluxos de trabalho das empresas
1. Marketing de conteúdo e SEO
As equipas de marketing criam registos blog.post para publicar artigos otimizados: usam website_meta_title, website_meta_description e seo_name para melhorar o posicionamento e o campo content para o texto completo. As tags ajudam a agrupar temas e a construir tópicos relevantes para os leitores e para os motores de busca.
2. Websites com vários blogs
Organizações mantêm coleções distintas — por exemplo Notícias, Lançamentos ou Documentação Técnica — cada uma representada por um blog.blog contendo muitos blog.post. O campo blog_id é a ligação que permite aos visitantes navegar por secções e aplicar filtros por etiquetas.
3. Conteúdo gerido por API
Sistemas externos podem criar e atualizar blog.post por XML‑RPC/JSON‑RPC: cenários comuns incluem importação automática de um CMS, sincronização com um blog headless ou geração de posts a partir de fluxos internos. O modelo está exposto via API para operações de create/read/update/search.
4. Publicação programada
Basta definir post_date num momento futuro e marcar website_published como True: o Odoo revela o artigo quando a data chega, facilitando calendários editoriais e campanhas temporizadas.
5. Colaboração multi‑autor
Com author_id e o mail.thread activados, várias pessoas podem colaborar no mesmo artigo: autores são atribuídos, seguidores recebem notificações e o chatter permite comentários internos antes da publicação.
Como os desenvolvedores ampliam este modelo
Os desenvolvedores estendem blog.post através de padrões bem definidos no Odoo, sendo a herança de modelos a via principal.
Herança de modelo
Defina _inherit = 'blog.post' para ampliar o modelo: adicione novos campos, sobrescreva métodos ou imponha constraints. Manter a extensão num módulo separado facilita atualizações. Lembre‑se também de como blog.post herda funcionalidades de mail.thread e website.published.mixin antes de alterar comportamentos.
Adicionar campos
Acrescente campos personalizados no seu módulo herdado — Char, Many2one, Boolean, Integer, Text, Selection, conforme a necessidade. Para metadados (por exemplo tempo de leitura ou categorias internas), crie campos e exponha‑os nas vistas. Use o prefixo x_ para evitar colisões com campos de terceiros.
Extensões em Python
Sobrescreva create, write ou unlink para introduzir lógica ao guardar, sempre chamando super() para preservar o comportamento base. Tenha cuidado com campos calculados da mistura website_published e com a gestão de URLs; pode ser necessário sobrescrever _compute_website_url para regras de URL específicas.
Odoo Studio
Odoo Studio permite adicionar campos sem escrever código — rápido para personalizações simples e metadados adicionais. Para lógica complexa, integrações via API ou personalizações sustentáveis, é preferível criar módulos próprios. Lembre‑se que o modelo blog.post está totalmente acessível pelas APIs XML‑RPC e JSON‑RPC.
Boas práticas
- Defina website_meta_title e website_meta_description em cada artigo para melhorar a visibilidade nos motores de busca.
- Utilize teaser_manual quando o excerto automático não refletir bem o artigo — uma sinopse pensada costuma obter melhores cliques nas listagens.
- Especifique seo_name em posts estratégicos para controlar o slug; evite carateres especiais que possam comprometer URLs.
- Ao publicar via integrações, altere website_published para colocar o post online — não escreva em is_published, que é apenas leitura.
- Use tag_ids para classificação consistente: crie e reutilize etiquetas pensadas em temas e categorias antes de as atribuir aos posts.
Erros frequentes
- Escrever em is_published em vez de website_published. is_published é um campo calculado e só leitura; para publicar/despublicar use sempre website_published.
- Esquecer de definir blog_id. Esse campo é essencial — sem ele o post pode não aparecer corretamente no site.
- Deixar website_meta_description vazio. Os motores de busca podem retirar fragmentos aleatórios da página; forneça sempre uma descrição clara de cerca de 150–160 caracteres.
- Sobrescrever métodos centrais sem chamar
super(). Isso pode quebrar funcionalidades do website.published.mixin ou do mail.thread e causar comportamentos inesperados. - Criar seo_name duplicados no mesmo blog. Slugs idênticos provocam conflitos de URL — deixe o Odoo gerar automaticamente ou garanta unicidade.
Conclusão
O modelo blog.post é o núcleo do blog no Odoo: guarda artigos, conteúdo, metadados e estados de publicação. Conhecer os campos e as relações com blog.blog e blog.tag facilita a configuração, personalização e integração do conteúdo do seu website.
Seja a sua função a de consultor funcional a gerir o fluxo editorial ou a de programador a construir integrações, dominar o blog.post evita erros comuns e acelera o desenvolvimento.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo acompanha empresas na implementação, personalização e otimização do Odoo. Temos experiência em integrações por API e no design de módulos adaptados à arquitetura de dados do Odoo, incluindo modelos como o blog.post.
Se precisa de apoio na sua implementação Odoo — design de módulos, integrações ou otimizações — podemos ajudar a planear e executar a solução. Agende uma demonstração para discutirmos o seu projeto.