Introduktion
I Odoo beskriver modellerne, hvordan journaliseret forretningsdata er struktureret og gemt. Al tekst, billeder og metadata du arbejder med i bloggen ligger i en model, så modellen er selve skabelonen for indholdet.
Modeller udgør fundamentet i Odoos datamæssige opbygning: de definerer felttyper, relationer mellem poster og den forretningslogik, der kører på dataene. For både udviklere og konsulenter er det afgørende at forstå, hvordan modeller opererer for at kunne konfigurere, udvide og fejlfinde korrekt.
Denne gennemgang tager udgangspunkt i blog.post‑modellen — den konkrete datamodel, der driver blogfunktionaliteten i Odoo. Uanset om du publicerer fra backenden, synkroniserer indhold via API eller tilpasser frontend‑oplevelsen, vil du møde denne model.
Hvad er blog.post‑modellen
blog.post repræsenterer en enkelt blogartikel i Odoo: hver post i din blog er en række i denne model, og alle publikations‑egenskaber for artiklen findes her.
Modellen er en del af website_blog‑modulet og arbejder sammen med andre modeller som blog.blog (selve bloggen) og blog.tag (tags/kategorisering). Når en redaktør opretter eller ændrer en artikel i Odoo, oprettes eller ændres en blog.post‑post.
blog.post bygger på flere mixins. Den bruger fx mail.thread til chatter og followers og website.published.mixin til udgivelseslogik. Når du skal udvide eller ændre adfærd, er det vigtigt at kende disse arveforhold.
Det er en almindelig, vedvarende (stored) model — ikke en abstrakt eller transient model. Poster bliver gemt i databasen og kan hentes og manipuleres via Odoos API.
Væsentlige felter i modellen
Nedenfor finder du de vigtigste felter i blog.post. At kende disse gør det lettere at arbejde operativt med blogindhold og integrationer.
1. name
Type: Char. Feltet indeholder artikelens titel. Det er påkrævet og vises i lister, formularer og på selve websiden — samt i browserfanen og søgeresultater.
2. blog_id
Type: Many2one (blog.blog). Kobler posten til den blog eller kategori den hører til. Hver post tilhører én blog, hvilket gør det muligt at opdele indhold i sektioner som Nyheder, Produktnyheder eller Guides.
3. subtitle
Type: Char. Kort underoverskrift eller tagline, der vises under titlen. Godt til at øge læsbarhed og SEO ved at give en hurtig forklaring på artiklens fokus.
4. content
Type: Html. Artikelens hovedindhold—rig tekst med billeder og website‑snippets. Det er det primære felt, hvor hele artiklen gemmes.
5. teaser
Type: Text. Automatisk genereret uddrag fra content til brug i lister. Feltet er beregnet og kun til læsning, så det giver en konsistent forhåndsvisning.
6. teaser_manual
Type: Text. Manuel overskrivelse af teaser. Sæt dette når du vil have et skræddersyet resume, der adskiller sig fra artiklens første afsnit.
7. author_id
Type: Many2one (res.partner). Peger på forfatteren som kontakt eller bruger. Bruges på artikelsiden og i lister — vigtigt for multi‑forfatter setups.
8. author_name
Type: Char. Beregnet visningsnavn for forfatteren; falder tilbage til partnerens navn, når author_id er udfyldt. Feltet er kun til visning.
9. author_avatar
Type: Binary. Avatarbillede til forfatteren, vist ved siden af navnet. Valgfrit, men forbedrer visuel genkendelighed.
10. is_published
Type: Boolean. Indikerer om posten er synlig på websitet. Feltet er beregnet og kan ikke skrives direkte — brug website_published til at styre det.
11. website_published
Type: Boolean. Skrivebart flag for publicering. Sæt til True for at gøre posten live, False for kladde. Dette felt styrer is_published.
12. post_date
Type: Datetime. Den dato, der vises for besøgende som publikationsdato. Brugt til sortering og kan planlægges i fremtiden til timed udgivelser.
13. published_date
Type: Datetime. Den faktiske udgivelsesdato, sat automatisk når website_published bliver True. Vigtigt til analyser og rapportering.
14. active
Type: Boolean. Soft‑slet flag. Sættes til False for at arkivere poster uden at fjerne dem fuldstændigt fra databasen.
15. tag_ids
Type: Many2many (blog.tag). Tags til kategorisering og filtrering. Kan bruges sammen med kategorier for at skabe hierarkisk organisation af indhold.
16. visits
Type: Integer. Antal visninger. Feltet er læse‑kun og opdateres ved besøg — nyttigt til at finde populære artikler.
17. website_url
Type: Char. Den komplette URL‑sti til posten på websitet. Formatet følger patternet /blog/{blog‑seo‑navn‑id}/{post‑seo‑navn‑id} og er beregnet.
18. cover_properties
Type: Text. JSON‑streng med egenskaber for coverbilledet (positionering, overlay osv.). Frontenden bruger dette til at vise cover korrekt.
19. header_visible
Type: Boolean. Styrer om site‑headeren vises på postens side — nyttigt for fuldbredde eller indlejrede visninger.
20. footer_visible
Type: Boolean. Styrer om site‑footeren vises; ofte brugt sammen med header_visible.
21. seo_name
Type: Char. SEO‑venlig slug til URL‑en. Hvis tom genereres den ud fra titlen; undgå særtegn for at forhindre brudte links.
22. website_meta_title
Type: Char. Meta‑titel til søgemaskiner — vises i fanen og søgeresultater. En vigtig del af on‑page SEO.
23. website_meta_description
Type: Text. Meta‑beskrivelse vist i søgeresultater. Hold den på ca. 150–160 tegn for optimal visning.
24. website_meta_keywords
Type: Char. Meta‑keywords. Mindre relevant i dag, men kan stadig bruges i nogle systemer.
25. create_date
Type: Datetime. Tidspunktet hvor posten blev oprettet — styres automatisk og nyttigt til revisionsspor.
26. create_uid
Type: Many2one (res.users). Brugeren som oprettede posten. Automatisk sat og kun til visning.
27. write_date
Type: Datetime. Sidste redigeringsdato — hjælper med at se hvornår indhold sidst blev opdateret.
28. write_uid
Type: Many2one (res.users). Den bruger der sidst ændrede posten. Feltet er kun til visning.
29. display_name
Type: Char. Beregnet visningsnavn brugt i dropdowns og søgninger — kun til læsning.
30. website_id
Type: Many2one (website). I multi‑website setups angiver dette hvilken side posten tilhører; hvis tom kan posten vises på flere sites.
Hvordan modellen bruges i forretningsprocesser
1. Content‑marketing og SEO
Marketingteams opretter og redigerer blog.post‑poster for at publicere artikler. De bruger website_meta_title, website_meta_description og seo_name aktivt til at optimere synlighed, mens content‑feltet rummer selve artiklen. Tags gør indholdet søgbart og struktureret.
2. Flere blogs under samme installation
Virksomheder kan drive adskilte blogs (fx Nyheder, Produktopdateringer, Teknisk dokumentation). Hver blog.blog indeholder mange blog.post‑poster, og blog_id forbinder post til den rigtige sektion, så besøgende kan navigere og filtrere efter emne.
3. API‑drevet indholdsflow
Integrationer kan skabe og opdatere blog.post‑poster via XML‑RPC eller JSON‑RPC — fx import fra et CMS, synkronisering fra et headless setup eller automatisk oprettelse fra interne systemer. Odoos model‑API understøtter create, read, update og search på blog.post.
4. Planlagt udgivelse
Ved at sætte post_date i fremtiden og website_published til True kan du planlægge automatiske udgivelser. Det er praktisk til content‑kalendere og timed kampagner.
5. Multi‑forfatter samarbejde
Feltet author_id sammen med mail.thread gør det muligt at tildele forfattere, følge ændringer og bruge chatter til interne kommentarer, inden artiklen går live.
Hvordan udviklere udvider modellen
Udviklere udvider blog.post ved hjælp af Odoos arve‑ og udvidelsesmønstre — modelarv er det mest almindelige værktøj.
Modelarv
Brug _inherit = 'blog.post' i dit modul for at udvide modellen: tilføj nye felter, overskriv metoder eller indfør restriktioner. Hold ændringer i et separat modul for nemmere opgraderinger, og vær opmærksom på arven fra mail.thread og website.published.mixin når du overstyrer adfærd.
Tilføjelse af felter
Definér nye felter i din arvede model med de rette typer (Char, Many2one, Boolean, Integer, Text, Selection). Til metadata som læsetid eller særlige kategorier tilføjer du felter og eksponerer dem i views. Brug x_‑prefix på custom felter for at undgå navnekonflikter.
Python‑udvidelser
Overstyr create, write eller unlink for at indsætte forretningslogik — husk altid at kalde super() for at bevare standardadfærden. Vær især forsigtig med website_published og post_date, da mange felter er beregnede via website‑mixinen. Hvis du skal ændre URL‑logik, kan _compute_website_url overskrives.
Odoo Studio
Odoo Studio er praktisk til hurtige, kodefri tilføjelser af felter og visninger. Til simple metadata er det ofte tilstrækkeligt, men til avanceret logik, komplekse integrationer eller vedligeholdbare løsninger anbefales egentlige moduler. Blog.post er fuldt tilgængelig via Odoos XML‑/JSON‑RPC API.
Bedste praksis
- Indstil website_meta_title og website_meta_description for hver post — det øger chancerne for bedre synlighed i søgemaskiner.
- Brug teaser_manual i lister når den automatisk genererede teaser ikke fanger budskabet. Håndskrevne teasers konverterer ofte bedre.
- Sæt seo_name eksplicit for vigtige indlæg og undgå specialtegn, der kan lave uklare eller fejlbehæftede URL'er.
- Når du arbejder via API, brug website_published til at publicere — skriv ikke til is_published, da det er read‑only.
- Brug tag_ids til konsistent kategorisering: opret et kontrolleret sæt tags og genbrug dem på tværs af artikler for bedre filtrering.
Almindelige fejl
- At forsøge at skrive til is_published i stedet for website_published. is_published er beregnet og kan ikke ændres direkte — brug website_published.
- At glemme at sætte blog_id. Feltet er nødvendigt for korrekt visning; manglende blog‑tilknytning kan føre til at posten ikke vises som forventet.
- At lade website_meta_description stå tom. Søgemaskiner kan da trække et tilfældigt uddrag fra siden; lever altid en klar 150–160 tegns beskrivelse.
- At overskrive kernemetoder uden at kalde super(). Det kan bryde mixins som website.published eller funktionen i mail.thread.
- At lave duplikerede seo_name inden for samme blog. Det skaber URL‑konflikter — lad Odoo generere unik slug eller sørg for egen unikke navngivning.
Konklusion
blog.post er kernen i Odoos blogplatform: den opbevarer artikler, indhold, metadata og udgivelsesstatus. Kendskab til felterne og relationerne til blog.blog og blog.tag gør det lettere at konfigurere, tilpasse og integrere blogindhold effektivt.
Uanset om du er funktionel konsulent, indholdsansvarlig eller udvikler, vil et godt kendskab til blog.post spare tid og forebygge fejl i drift og integrationer.
Brug for hjælp til din Odoo‑implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi er særligt stærke i API‑integrationer og udvikling, og har mange års erfaring med Odoo‑datamodeller som blog.post.
Har du brug for hjælp til Odoo‑implementering, skræddersyede moduler eller integrationer, står vi klar til at hjælpe. Book en demo for at tage en uforpligtende snak om dit projekt.