Einleitung
In Odoo legen Modelle fest, wie Informationen strukturiert und dauerhaft abgelegt werden. Jede Geschäftsinformation — ob Artikel, Kontakt oder Rechnung — lebt in einem solchen Modell und bildet die Grundlage für Suchen, Filter und Integrationen.
Modelle sind das Rückgrat der Odoo‑Datenarchitektur. Sie definieren Felder, Beziehungen zwischen Datensätzen und die Geschäftslogik, die auf den Daten ausgeführt wird. Ein solides Verständnis der Modellstruktur ist sowohl für technische Entwickler als auch für funktionale Berater unerlässlich.
Dieser Beitrag konzentriert sich auf das blog.post‑Modell, das die Blog‑Funktionalität einer Odoo‑Webseite steuert. Egal ob Sie Beiträge per Oberfläche verfassen, per API importieren oder das Blogging‑Erlebnis anpassen — das blog.post‑Modell ist der zentrale Baustein.
Was ist das blog.post‑Modell?
Das blog.post‑Modell steht für einen einzelnen Blog‑Beitrag in Odoo. Jeder Datensatz entspricht einem Artikel, der auf Ihrer Website angezeigt werden kann.
Das Modell gehört zum Modul website_blog und arbeitet eng mit blog.blog (der eigentlichen Blog‑Sammlung) und blog.tag (zur Kategorisierung) zusammen. Wenn Sie einen Beitrag anlegen oder ändern, bearbeiten Sie ein blog.post‑Objekt.
Das Modell nutzt mehrere Mixins: etwa mail.thread für Chatter‑Funktionen und website.published.mixin für Veröffentlichungs‑Logik. Diese Vererbungen beeinflussen Verhalten und Felder — wichtig zu wissen, bevor man Erweiterungen vornimmt.
blog.post ist ein reguläres persistentes Modell, kein abstrakter oder transienter Datentyp. Beiträge werden in der Datenbank gespeichert und sind über die API abfragbar.
Wichtige Felder des Modells
Im Folgenden sind die wichtigsten Felder des blog.post‑Modells zusammengefasst. Wer sie kennt, arbeitet effizienter mit Blog‑Inhalten.
1. name
Typ: Char. Der Titel des Beitrags, Pflichtfeld. Er erscheint in Übersichten, Formularen und im Browser‑Tab und ist oft ein wichtiges Element für SEO.
2. blog_id
Typ: Many2one (blog.blog). Verknüpft den Beitrag mit seinem Blog‑Container. Jeder Beitrag gehört genau zu einem Blog und lässt sich so thematisch einordnen (z. B. News, Produktupdates, Anleitungen).
3. subtitle
Typ: Char. Kurzer Untertitel oder Slogan, sichtbar unter dem Titel auf der Beitragsseite und in Listen. Hilft Lesbarkeit und SEO.
4. content
Typ: Html. Der eigentliche Artikeltext mit Bildern und Website‑Snippets. Hier liegt der Hauptinhalt des Beitrags.
5. teaser
Typ: Text. Automatisch erstellte Vorschau aus dem Inhalt. Read‑only, wird in Blog‑Listen angezeigt.
6. teaser_manual
Typ: Text. Manuelle Zusammenfassung, die die automatische Vorschau ersetzt. Praktisch, wenn Sie einen prägnanteren Aufhänger wünschen.
7. author_id
Typ: Many2one (res.partner). Der Autor als Kontakt oder Benutzer. Wichtig für Multi‑Author‑Blogs und Autorenprofile.
8. author_name
Typ: Char. Berechneter Anzeigename des Autors, fällt auf author_id zurück. Read‑only.
9. author_avatar
Typ: Binary. Autorenbild, optional und in Beitragsansichten sichtbar.
10. is_published
Typ: Boolean. Zeigt an, ob der Beitrag live ist. Berechnetes, schreibgeschütztes Feld — nur zur Anzeige.
11. website_published
Typ: Boolean. Schreibbares Feld zum Veröffentlichen/Zurückziehen. Auf True setzen macht den Beitrag öffentlich; auf False wird er als Entwurf behandelt.
12. post_date
Typ: Datetime. Angezeigtes Veröffentlichungsdatum, nutzbar für Sortierung und geplante Veröffentlichungen.
13. published_date
Typ: Datetime. Tatsächliches Datum der Veröffentlichung; wird automatisch gesetzt, wenn website_published True wird.
14. active
Typ: Boolean. Archivierungsflag (Soft‑Delete). Ist das Feld False, bleibt der Datensatz erhalten, wird aber aus Standardansichten ausgeblendet.
15. tag_ids
Typ: Many2many (blog.tag). Schlagworte zur Kategorisierung und Filterung; Tags können auch hierarchisch organisiert werden.
16. visits
Typ: Integer. Besuchszähler, read‑only. Nützlich für Auswertungen und zur Anzeige populärer Beiträge.
17. website_url
Typ: Char. Voller Pfad zum Beitrag auf der Website, read‑only. Typisches Format: /blog/{blog‑slug‑id}/{post‑slug‑id}.
18. cover_properties
Typ: Text. JSON mit Einstellungen zur Cover‑Darstellung (Position, Overlay etc.), wird vom Frontend verwendet.
19. header_visible
Typ: Boolean. Steuerung, ob Header der Website auf der Beitragsseite angezeigt wird — nützlich für Vollbreiten‑Layouts.
20. footer_visible
Typ: Boolean. Steuerung der Sichtbarkeit des Footers; oft gemeinsam mit header_visible eingesetzt.
21. seo_name
Typ: Char. SEO‑freundlicher URL‑Slug. Wird aus dem Titel generiert, kann aber manuell gesetzt werden und beeinflusst die URL‑Struktur.
22. website_meta_title
Typ: Char. Meta‑Title für Suchmaschinen und Browser‑Tabs — wichtig für SEO‑Ranking und Klickrate.
23. website_meta_description
Typ: Text. Meta‑Description, idealerweise 150–160 Zeichen; wird in Suchergebnissen als Snippet angezeigt.
24. website_meta_keywords
Typ: Char. Meta‑Keywords; heute weniger relevant, können aber von manchen Systemen noch genutzt werden.
25. create_date
Typ: Datetime. Zeitpunkt der Anlage des Datensatzes, automatisch gesetzt — nützlich für Reporting und Audit.
26. create_uid
Typ: Many2one (res.users). Nutzer, der den Datensatz erstellt hat; automatisch gesetzt und read‑only.
27. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung — hilfreich, um Aktualisierungszyklen zu verfolgen.
28. write_uid
Typ: Many2one (res.users). Nutzer, der zuletzt verändert hat; read‑only.
29. display_name
Typ: Char. Berechneter Anzeigename, genutzt in Many2one‑Dropdowns und Suchergebnissen; read‑only.
30. website_id
Typ: Many2one (website). Bei Multi‑Website‑Setups gibt dieses Feld an, zu welcher Website der Beitrag gehört; bleibt es leer, kann der Beitrag auf mehreren Websites erscheinen.
Wie dieses Modell in Geschäftsprozessen eingesetzt wird
1. Content‑Marketing und SEO
Marketing‑Teams legen blog.post‑Einträge an, pflegen content sowie die SEO‑Felder (website_meta_title, website_meta_description, seo_name) und verwenden Tags zur thematischen Sortierung. Gut gepflegte Metadaten verbessern Sichtbarkeit und Klickrate in Suchmaschinen.
2. Mehrere Blogs auf einer Website
Unternehmen betreiben oft mehrere Blogs (z. B. News, Produktneuheiten, technische Anleitungen). blog_id koppelt Beiträge an den jeweiligen Bereich, sodass Besucher gezielt nach Rubriken oder Tags filtern können.
3. API‑gesteuerte Inhalte
Externe Systeme importieren oder erzeugen Beiträge per XML‑RPC/JSON‑RPC — etwa ein Headless‑CMS oder interne Content‑Pipelines. Das blog.post‑Modell ist vollständig über die Odoo‑API zugänglich (create, read, update, search).
4. Geplante Veröffentlichungen
Setzen Sie post_date in die Zukunft und website_published auf True: Odoo zeigt den Beitrag zum eingestellten Datum an. Ideal für Redaktionskalender und zeitlich gesteuerte Kampagnen.
5. Mehrautoren‑Workflow und Zusammenarbeit
author_id plus mail.thread ermöglichen Zuweisung von Autoren, interne Kommentare und Benachrichtigungen für Follower. So lassen sich Beiträge kollaborativ vorbereiten und freigeben.
Wie Entwickler das Modell erweitern
Entwickler erweitern blog.post mit bewährten Odoo‑Mustern. Die Haupttechnik ist die Modellvererbung.
Modell‑Vererbung
Verwenden Sie _inherit = 'blog.post', um das Modell zu erweitern. So fügen Sie Felder hinzu, überschreiben Methoden oder definieren Constraints, ohne den Core zu verändern. Achten Sie auf die vorhandenen Mixins wie mail.thread und website.published.mixin beim Überschreiben.
Felder hinzufügen
In der abgeleiteten Klasse definieren Sie neue Felder (Char, Many2one, Boolean, Integer, Text, Selection). Für eigene Metadaten wie Lesezeit oder interne Kategorien empfiehlt sich das Hinzufügen von Feldern sowie ihre Darstellung in Views. Nutzen Sie das Präfix x_ für benutzerdefinierte Felder, um Konflikte zu vermeiden.
Python‑Erweiterungen
Überschreiben Sie Methoden wie create, write oder unlink, um zusätzliche Logik einzubauen. Rufen Sie super() auf, um Basisverhalten beizubehalten. Seien Sie vorsichtig bei Feldern, die vom Website‑Mixin berechnet werden (z. B. website_published) — bei Bedarf _compute_website_url anpassen.
Odoo Studio
Odoo Studio erlaubt schnelle, codefreie Feldergänzungen — praktisch für kleine Anpassungen. Für komplexe Integrationen, Geschäftslogik oder maßgeschneiderte Views sind Custom‑Module jedoch langfristig wartbarer. Das blog.post‑Modell bleibt in beiden Wegen über die API nutzbar.
Best Practices
- Pflegen Sie website_meta_title und website_meta_description für jeden Beitrag — das verbessert die Auffindbarkeit in Suchmaschinen.
- Nutzen Sie teaser_manual, wenn die automatisch erzeugte Vorschau nicht passt. Manuelle Teaser erhöhen oft die Klickrate in Listen.
- Setzen Sie seo_name gezielt für wichtigen Content und vermeiden Sie Sonderzeichen, die URLs ungültig machen können.
- Bei API‑Integration immer website_published verwenden, um Beiträge zu veröffentlichen. is_published ist nur eine Anzeige und nicht zum Schreiben gedacht.
- Verwenden Sie tag_ids konsequent für eine konsistente Kategorisierung. Legen Sie Tags zentral an und nutzen Sie sie wiederholt, statt immer neue anzulegen.
Häufige Fehler
- Schreiben Sie nicht in is_published statt in website_published. is_published ist ein berechnetes Feld und lässt sich nicht direkt setzen.
- Vergessen, blog_id zu setzen. Das Feld ist essentiell — ohne Blogzuordnung erscheinen Beiträge häufig nicht korrekt.
- Keine website_meta_description angeben. Suchmaschinen ziehen dann möglicherweise willkürliche Textstellen als Snippet, was die Klickrate verringern kann. Immer eine prägnante 150–160 Zeichen Beschreibung hinterlegen.
- Core‑Methoden überschreiben, ohne super() aufzurufen. Dadurch können Mixins wie website.published oder mail.thread unerwartet gestört werden.
- Doppelte seo_name‑Werte innerhalb desselben Blogs anlegen. Das führt zu URL‑Konflikten. Lassen Sie Odoo Slugs automatisch erstellen oder stellen Sie Eindeutigkeit sicher.
Fazit
Das blog.post‑Modell ist das Herzstück des Odoo‑Blogsystems: Es speichert Artikel, Inhalte, Metadaten und den Veröffentlichungsstatus. Wer die Felder und die Beziehungen zu blog.blog und blog.tag kennt, kann Inhalte zielgerichtet konfigurieren, anpassen und automatisieren.
Egal ob Sie Inhalte redaktionell managen oder Integrationen programmieren — ein tiefes Verständnis des blog.post‑Modells verhindert Fehler und spart Zeit.
Brauchen Sie Hilfe bei Ihrer Odoo‑Einführung?
Dasolo unterstützt Unternehmen bei der Einführung, Anpassung und Optimierung von Odoo. Wir haben umfangreiche Erfahrung mit Odoo‑Datenarchitekturen und Modellen wie blog.post sowie mit API‑Integrationen.
Wenn Sie Unterstützung bei Odoo‑Implementierung, individuellen Modulen oder Integrationen benötigen, sprechen Sie uns an. Demo vereinbaren um Ihr Projekt zu besprechen.