Innledning
I Odoo beskriver modeller hvordan informasjon organiseres og lagres. Alt av forretningsdata du jobber med — artikler, kontakter, ordre — lever i én eller flere modeller som definerer struktur og regler.
Modeller utgjør ryggraden i Odoos datamodell. De angir felttyper, relasjoner mellom objekter og forretningslogikk som valideringer eller beregninger. Både tekniske konsulenter og funksjonelle brukere tjener på å ha grunnleggende forståelse av hvordan modeller fungerer.
Her går vi nærmere inn på modellen blog.post, som håndterer bloggartikler på Odoo-nettsteder. Enten du publiserer via grensesnittet, oppretter innhold gjennom API-er eller tilpasser fremvisningen, vil du møte denne modellen.
Hva er modellen blog.post
Modellen blog.post representerer én enkelt bloggpost i Odoo. Hver post er en egen databaseoppføring som vises som en artikkel på nettstedet ditt.
blog.post er en del av nettstedets bloggmodul og fungerer sammen med andre modeller som blog.blog (selve bloggen/kanalen) og blog.tag (kategorisering). Når du oppretter eller endrer en artikkel i nettstedets editor, oppdaterer du et blog.post-objekt bak kulissene.
Modellen bygger på flere mixins for å få ferdig funksjonalitet. For eksempel håndteres følgere og chatter via mail.thread, mens publiseringslogikk ligger i website.published.mixin. Kjennskap til disse arveveiene er nyttig når du utvider modellen.
blog.post er en vanlig, vedvarende modell — ikke transient eller abstrakt. Postene ligger lagret i databasen og er tilgjengelige for spørringer og API-operasjoner over tid.
Viktige felter i modellen
Nedenfor er feltene du oftest vil bruke i blog.post. Å forstå dem gjør det enklere å redigere, filtrere og integrere blogginnhold.
1. name
Type: Char. Dette er postens tittel. Den vises i lister, i selve artikkelen og i nettleserfanen. Feltet er påkrevd og sentralt for både brukere og søkemotoroptimalisering.
2. blog_id
Type: Many2one (blog.blog). Kobler posten til sin overordnede blogg eller kanal. Bruk denne til å holde artikler organisert i for eksempel Nyheter, Produkter eller Teknisk dokumentasjon.
3. subtitle
Type: Char. En kort undertekst under hovedtittelen. Gir ekstra kontekst og kan forbedre brukeropplevelsen i listinger og på selve artikkelen.
4. content
Type: Html. Selve artikkelteksten med mulighet for rik formatering, bilder og innebygde snippets fra nettstedet. Dette er det viktigste innholdsfeltet for leserne.
5. teaser
Type: Text. Automatisk generert utdrag fra innholdet som brukes i listinger. Feltet regnes som beregnet og er vanligvis skrivebeskyttet.
6. teaser_manual
Type: Text. Manuell overskrivning av utdraget. Bruk dette når du vil presentere en spesialtilpasset ingress i stedet for en automatisk generert teaser.
7. author_id
Type: Many2one (res.partner). Referanse til forfatteren. Kan knyttes til en kontakt eller bruker for å vise hvem som har skrevet posten — nyttig for flerskribent-blogger.
8. author_name
Type: Char. Visningsnavnet til forfatteren. Vanligvis beregnet fra author_id og skrivebeskyttet, brukt i visninger og listinger.
9. author_avatar
Type: Binary. Bildefelt for forfatterens avatar. Valgfritt, men gir et mer visuelt uttrykk ved forfatterpresentasjon.
10. is_published
Type: Boolean. Indikerer om posten er publisert og synlig. Dette feltet er beregnet og bør ikke endres direkte — det reflekterer publiseringsstatusen.
11. website_published
Type: Boolean. Det skrivbare publiseringsfeltet. Sett til True for å gjøre posten synlig på nettsiden, False for kladd. Dette styrer is_published.
12. post_date
Type: Datetime. Den publiseringsdatoen som vises til brukere og brukes ved sortering. Kan settes frem i tid for planlagt publisering.
13. published_date
Type: Datetime. Når posten faktisk ble publisert. Automatisk satt når website_published endres til True, nyttig i analyser og rapporter.
14. active
Type: Boolean. Arkiveringsflagget. Sett False for å skjule posten fra standardvisninger uten å slette den fysisk fra databasen.
15. tag_ids
Type: Many2many (blog.tag). Etiketter for kategorisering. Bruk tags for filtering, oppdagbarhet og emnegruppering på nettstedet.
16. visits
Type: Integer. Antall visninger for posten. Feltet er lesebeskyttet og oppdateres når besøk registreres — praktisk for å finne populære artikler.
17. website_url
Type: Char. Den fullstendige URL-en til artikkelen på nettstedet. Generert av systemet og nyttig når du trenger direktelenker til posten.
18. cover_properties
Type: Text. JSON-lignende tekst som beskriver egenskaper for forsidebildet (posisjonering, overlay osv.). Brukes av frontenden for visuell presentasjon.
19. header_visible
Type: Boolean. Styrer om nettstedets header skal vises på artikksiden — nyttig for innlegg som skal vises i fullbredde eller innebygd i andre sider.
20. footer_visible
Type: Boolean. Styrer synlighet av footer på siden. Ofte brukt sammen med header_visible for å lage rene landingssider.
21. seo_name
Type: Char. SEO-vennlig sti/slug for URL-en. Hvis ikke satt, genereres den automatisk fra tittelen. Hold slugs enkle og uten spesialtegn.
22. website_meta_title
Type: Char. Meta-tittel for søkemotorer og nettleserfaner. Viktig for søkesynlighet og klikkfrekvens i søkeresultater.
23. website_meta_description
Type: Text. Meta-beskrivelse som vises i søkeresultater. Hold den rundt 150–160 tegn for best presentasjon i søkemotorer.
24. website_meta_keywords
Type: Char. Gamle metanøkkelordfeltet. Ikke kritisk for moderne SEO, men enkelte systemer kan fortsatt bruke det.
25. create_date
Type: Datetime. Tidspunktet posten ble opprettet. Administreres automatisk av Odoo og gir nyttig historikk for rapportering.
26. create_uid
Type: Many2one (res.users). Brukeren som opprettet posten. Automatisk satt og nyttig ved sporbarhet.
27. write_date
Type: Datetime. Tidspunkt for siste endring. Gir innsikt i når innhold sist ble oppdatert.
28. write_uid
Type: Many2one (res.users). Brukeren som sist redigerte posten. Feltet er skrivbeskyttet og administreres av systemet.
29. display_name
Type: Char. Beregnet visningsnavn som brukes i oppslag og dropdowns — vanligvis avledet fra tittelen.
30. website_id
Type: Many2one (website). Angir hvilket nettsted posten tilhører i flernettstedsoppsett. Når tomt kan innholdet vises på alle nettsteder avhengig av konfigurasjon.
Hvordan denne modellen brukes i forretningsprosesser
1. Innholdsmarkedsføring og SEO
Markedsførere oppretter blogginnlegg i systemet og benytter felter som website_meta_title, website_meta_description og seo_name for å styrke søkesynlighet. Hovedinnholdet legges i content, mens tags bidrar til emneorganisering og navigasjon.
2. Flerkanal-blogger
Organisasjoner kan kjøre flere separate blogger — for eksempel Nyheter, Produktoppdateringer og Tekniske guider. Hver blogg (blog.blog) samler mange blog.post-poster, og blog_id brukes for å holde dem adskilt og synlige for besøkende.
3. Innhold via API
Systemintegrasjoner kan opprette og oppdatere blogginnlegg via Odoos API (XML-RPC/JSON-RPC). Vanlige tilfeller er import fra et eksternt CMS, synk mot headless-løsninger eller automatisk opprettelse fra interne verktøy.
4. Planlagt publisering
Vil du publisere senere? Sett post_date frem i tid og website_published til True. Odoo kan vise innholdet automatisk når den planlagte datoen inntreffer — praktisk for kampanjeplaner.
5. Flerskribentarbeid og samarbeid
Feltet author_id kombinert med mail.thread gjør det enkelt å tildele forfattere, følge endringer og diskutere innhold internt i chatter før artikler publiseres.
Hvordan utviklere utvider modellen
Utviklere bygger videre på blog.post ved hjelp av Odoos arve- og utvidelsesmønstre. Det gir mulighet for nye felt, logikk og tilpassede visninger.
Modellarv
For å endre bloggen bruker du _inherit = 'blog.post' i ditt modulmanifest. Der kan du legge til nye felter, overskrive metoder eller legge inn valideringer. Husk å ta hensyn til mixin-ene som allerede gir funksjonalitet, som mail.thread og website.published.mixin.
Legge til felter
Når du trenger ekstra metadata — for eksempel lesetid, interne kategorier eller tilpassede flags — definerer du nye felt med passende datatyper (Char, Many2one, Selection osv.). Bruk gjerne x_-prefikset for egendefinerte felt for å unngå navnekonflikter.
Python-utvidelser
Overstyr create, write eller unlink for å sette inn ekstra logikk ved opprettelse, oppdatering eller sletting. Kall alltid super() der det er nødvendig, og vær oppmerksom på at publiseringsfelt og beregnede felt styres av mixin-logikk.
Odoo Studio
Odoo Studio gir et raskt, kodefritt alternativ for å legge til felt og endre skjemaer. Det er fint for enkle tillegg, men for mer kompleks logikk, API-integrasjoner eller vedlikehold i produksjon er en modulbasert løsning mer robust.
Beste praksis
- Sett alltid website_meta_title og website_meta_description for viktige innlegg. Riktige meta-felt øker sannsynligheten for gode plasseringer og høyere klikkrate i søk.
- Bruk teaser_manual når den automatiske utdraget ikke fanger poenget. Skreddersydde ingresser driver ofte bedre trafikk fra oversiktsider.
- Angi seo_name eksplisitt for viktige artikler du vil kontrollere URL-en for. Unngå norske spesialtegn og mellomrom som kan skape uheldige lenker.
- Ved API-publisering: skriv til website_published for å endre synlighet. Ikke forvent at is_published kan settes direkte — det er beregnet av systemet.
- Bruk tag_ids for konsekvent kategorisering. Opprett et sett standard-tagger på forhånd og gjenbruk dem for bedre filtrering og konsistens.
Vanlige feil
- Å forsøke å skrive til is_published i stedet for website_published. is_published er beregnet og skrivebeskyttet — publisering må gjøres via website_published.
- Å glemme å sette blog_id. Feltet er essensielt for at posten skal vises riktig i rette bloggkanaler; uten blog-id kan artikkelen bli utilgjengelig i forventede visninger.
- La website_meta_description stå tom. Søk bruker da ofte et tilfeldig utdrag fra siden, noe som gir uforutsigbar og ofte mindre attraktiv søketekst.
- Overstyre kjernemetoder uten å kalle super(). Det kan bryte eksisterende funksjonalitet fra mixins som håndterer publisering eller chatter.
- Opprette duplikate seo_name-verdier i samme blogg. Det fører til URL-konflikter. La Odoo generere unike slugs eller sørg for egen unikhetslogikk.
Konklusjon
blog.post er kjernen i Odoos bloggfunksjonalitet. Den lagrer artikler, tekstinnhold, metadata og publiseringsstatus. Å kjenne feltene og relasjonene til blog.blog og blog.tag gjør det enklere å konfigurere, skreddersy og koble innhold til andre systemer.
Enten du jobber funksjonelt med innhold eller teknisk med integrasjoner, sparer du tid og unngår feil ved å ha grunnleggende kontroll på hvordan blog.post er bygget opp og brukes.
Trenger du hjelp med Odoo-implementasjonen din?
Dasolo hjelper selskaper med implementasjon, skreddersøm og optimalisering av Odoo. Vi har erfaring med API-integrasjoner og dyp forståelse av Odoos datamodell, inkludert modeller som blog.post.
Trenger du hjelp med modulanpassinger, integrasjoner eller rådgivning rundt Odoo? Vi bistår gjerne med prosjektvurdering og gjennomføring. Book en demo for å diskutere prosjektet ditt.