Innledning
Når man begynner å utvikle for Odoo, dukker arveksempler opp overalt. Odoo sin ORM er laget for å la modeller utvide hverandre og gjenbruke felter uten å kopiere data eller skrive unødig kode.
Arvede felt er selve mekanismen som gjør dette mulig. De lar én modell vise og bruke et felt som i realiteten hører til en annen modell, noe som gir en renere og mer konsistent datamodell.
I denne guiden går vi gjennom hva arvede felt er, hvilke arvemekanismer i Odoo som skaper dem, hvordan de oppfører seg i databasen, og hvordan du best utnytter dem i tilpasningsprosjekter.
Hva betyr det at et felt er arvet i Odoo?
Et felt regnes som arvet når en modell får tilgang til et felt som er definert på en annen modell ved hjelp av en av Odoos arveteknikker, i stedet for å opprette et helt nytt, identisk felt.
Dette forklarer hvorfor samme navn- eller kontaktfelt viser seg flere steder i systemet uten at data kopieres. Ulike modeller peker mot samme kilde, slik at informasjon bare trenger å vedlikeholdes ett sted.
De tre arvetypene i Odoo
Odoo har tre forskjellige måter å arve modellstruktur på, og hver av dem påvirker felthåndteringen på sin egen måte.
1. Klassisk arv
Klassisk arv betyr at du bygger videre på en eksisterende modell uten å definere et nytt modellnavn. Du legger til felter og funksjoner direkte på modellen; ingen ny tabell opprettes i databasen.
Dette er den vanligste tilnærmingen for å legge til felter i standardmodeller. Når du installerer funksjonalitet som CRM, blir ekstra felter lagt til res.partner-tabellen i samme databaseobjekt.
2. Prototype-arv
Når du både bruker _inherit og samtidig setter et nytt _name, opprettes en ny modell som starter som en kopi av foreldre-modellen, men får sin egen tabell. Feltene kopieres inn i den nye tabellen og endringer påvirker ikke forelderen.
Denne metoden brukes når du ønsker en helt ny modell som ligner på en eksisterende, men som må leve separat i databasen.
3. Delegasjonsarv
Med _inherits oppretter barnet en Many2one-lenke til forelderen og «ekspanderer» foreldrefeltene som om de var egne. Dataene lagres på foreldretabellen, ikke på barnets tabell.
Delegasjonsarv er ofte det som menes med arvede felt i streng forstand: feltene du ser på barnet, leses og skrives direkte mot forelderens data uten duplisering.
Et tydelig eksempel i standard Odoo er res.users som er koblet til res.partner: brukerinformasjon som navn og e-post ligger på partneren og vises på brukerposten via delegasjon.
Slik fungerer arvede felt
Hva skjer i praksis ved delegasjon?
Når en modell benytter _inherits, setter ORM-en opp lenken mellom to tabeller. Hver gang du leser et arvet felt på barnerecorden, følger Odoo automatisk Many2one-lenken til forelderen og returnerer verdien.
Når du skriver til et arvet felt fra barnet, blir endringen lagret direkte på forelderen. For utvikleren oppfører feltet seg som om det tilhører barnet, men fysisk ligger dataene alltid hos forelderen.
En viktig konsekvens er at data ikke dupliseres. En oppdatering på forelderen vises umiddelbart der hvor den refereres, uten behov for synkronisering.
Klassisk arv og databasen
Ved klassisk arv legger du nye felt rett i eksisterende modellens tabell — det opprettes ingen ekstra tabell. Dette er en ryddig og mye brukt metode for å utvide standardmodeller i Odoo.
Related-felt som en lettvektsarv
Et related-felt er en beregnet felt-type som henter verdier gjennom en relasjonskjede. Det er ikke samme som modell-arv, men lar deg vise data fra en tilknyttet post uten å endre modellstrukturen.
For eksempel kan en salgsordre få et partner_country_id som peker på partner_id.country_id. Feltet ser ut som et lokalt felt på ordren, men innholdet kommer fra partneren.
Related-felt kan settes til store=True for å lagre verdien i databasen. Det gir raskere søk og filtrering, men øker lagringsbehovet og krever at verdien rekalkuleres ved endringer.
Hvordan felter kobles sammen ved kjøring
Når Odoo laster en modell, bygger det en komplett oversikt over feltene, inkludert arvede felt. Systemet vet ved oppstart hvor hver verdi hentes fra — egen tabell, foreldretabell via delegasjon eller en relasjonssti — og dette lagres i cache for ytelse.
Praktiske forretningsscenarier
Arvede felt er mer enn teknisk fiks; de løser praktiske problem for bedrifter ved å holde data konsistente gjennom systemet uten duplisering.
1. CRM og salg: kontaktinfo
Når en selger oppretter en lead, hentes navn, telefon og e-post fra partneren via Many2one. Endres partnerens opplysninger, oppdateres alle tilknyttede leads, tilbud og ordre automatisk.
Her jobber klassisk arv og related-felt sammen: CRM utvider res.partner med egne felt, mens salgsmodulen viser partnerdata videre uten å kopiere dem.
2. Produkter og varianter
Produktmodellen bruker delegasjonsarv for å separere mal (template) og variant (product.product). Felter som gjelder alle varianter — navn, kategori, pris — ligger på malen, mens variantspesifikke attributter ligger på variantposten.
Dette gjør at du kan ha mange varianter av samme produkt uten å lagre fellesbeskrivelser flere ganger.
3. Brukere og kontakter
Brukermodellen arver partnerfelt via _inherits, så e-post, telefon og adresse finnes på partneren og vises på brukeren. En endring på partneren synker dermed direkte inn i brukeroppføringen.
4. Lager: varebevegelser og produktinfo
Varebevegelseslinjer viser produktbeskrivelser som kommer fra produktmalen via relasjoner. Lagerpersonell får oppdatert produktinfo i plukklister uten at lageret må duplisere data.
5. Regnskap: fakturalinjer
Fakturalinjer refererer produkter og partnere; navn, konto og skatteoppsett hentes gjennom relasjoner slik at regnskap og salg ser samme kilde og dermed samme informasjon.
Hvordan opprette eller tilpasse arvede felt
Bruke Odoo Studio
Odoo Studio gir en visuell måte å legge til felt og tilpasse skjemaer uten kode. Når du legger til et felt i Studio, gjør verktøyet i praksis en klassisk utvidelse av modellen.
Studio kan også opprette related-felt: du peker på en relasjonssti fra gjeldende modell og Studio lager et felt som leser verdien fra kilden — for eksempel kundens land eller MVA-nummer fra partneren.
For funksjonelle brukere og konsulenter er Studio ofte riktig verktøy: den håndterer feltnavn, databaseendringer og plassering i UI automatisk.
Tekniske tilpasninger i Python
Utviklere definerer arvede felt i Python ved å bruke models.Model og Odoo sin felt-API.
Klassisk arv for å legge til et felt på en eksisterende modell:
Eksempel: du utvider crm.lead ved å legge til et flytallfelt for estimert kontraktsverdi via _inherit.
Delegasjonsarv for å opprette en ny modell som deler felt fra en eksisterende:
Eksempel: en egen profilmodell kan bruke _inherits mot res.partner og ha partner_id som Many2one, slik at partnerfeltene blir tilgjengelige på profilen.
Related-felt for å vise en verdi fra en tilknyttet post:
Eksempel: på sale.order kan du definere partner_country_id som related='partner_id.country_id' og sette store=True hvis du trenger å filtrere eller gruppere på det.
Gjennom XML-RPC API (fjernkonfigurasjon)
Du kan også opprette felt programmatisk via Odoo sin XML-RPC API ved å lage oppføringer i ir.model.fields — samme resultat som Studio gir, men egnet for automatisert utrulling.
For et related-felt via API oppretter du ir.model.fields med riktig ttype og angir related-stien. Dette passer godt til scripting av oppsett og massekonfigurasjon.
Anbefalt praksis
Velg riktig arvetype for oppgaven
Bruk klassisk arv når du bare vil legge til felt eller metoder på en eksisterende modell. Delegasjonsarv bør brukes når du faktisk trenger separate, lenkede postsett — altså når konseptet ikke naturlig er en kontakt i seg selv.
Foretrekk related-felt for leseformål
Hvis du kun trenger å vise en verdi fra en tilknyttet post i skjermbilder eller rapporter, er et related-felt enklere og mer vedlikeholdbart enn å bygge en delegert struktur.
Vær varsom med store=True på related-felt
Å lagre related-felt i databasen gir raskere søk, men gjør at verdien blir en kopi som må rekalkuleres ved endringer. Lagre kun når du virkelig trenger ytelsesfordelen for filtrering eller sortering.
Bruk alltid prefikset x_ på egendefinerte felt
Alle felter du legger til i standardmodeller bør ha x_-prefiks eller være navngitt med modulnavn for å unngå kollisjoner med fremtidige Odoo-felt.
Dokumenter arvkjeden
I komplekse tilpasninger er det lurt å notere hvor felt kommer fra. Et felt som x_country_code på salg kan ellers være vanskelig å spore tilbake til partner_id.country_id.code uten dokumentasjon.
Håndter kaskadeslett riktig
Ved delegasjonsarv lages foreldreposten gjerne automatisk ved opprettelse. Når barnet slettes bør forelderen normalt også slettes — bruk ondelete='cascade' på Many2one for å unngå foreldreløse poster.
Vanlige feil og fallgruver
Forvirring mellom arvetypene
En vanlig feil er å sette både _inherit og _name når man kun mente å utvide en modell. Det lager en helt ny modell i stedet for å bygge videre på den eksisterende — sjekk alltid definisjonen din.
Glemme å opprette foreldreposten ved _inherits
Ved programmatisk opprettelse må du sikre at foreldreposten blir laget eller at ORM-en håndterer det. Hvis ikke får du constraint-feil fordi lenken mangler.
Prøve å endre felttype via arv
Du kan ikke endre typen til et eksisterende felt gjennom arv — bare enkelte attributter som label eller help kan overskrives. Å forsøke en type-endring vil føre til installasjonsfeil.
Overforbruk av lagrede related-felt
Å sette store=True på alle related-felt øker databasestørrelse og rekalkuleringsarbeid. Bruk lagring selektivt, spesielt hvis kilden endres ofte.
Tro at adgangsregler følger barnet automatisk
Ved delegasjon ligger feltene på foreldremodellen, så tilgangsregler på barnet påvirker ikke nødvendigvis lesetilgang gjennom forelderen. Gjennomgå sikkerhetsregler på begge modeller.
Oppsummering
Arvede felt er grunnleggende i Odoo-arkitekturen. Forholdet mellom brukere/partnere, produkter/maler og salg/kundeinfo bygger på disse prinsippene for å unngå inkonsistens.
Når du forstår hvilken arvetype som passer, når et related-felt er bedre, og hvordan disse oppfører seg i databasen, jobber du raskere og med mindre feilsøking.
Hovedpoenget er enkelt: Odoo er laget for at data skal bo ett sted og brukes mange steder. Det er kjernen i arvede felt og grunnen til at systemet kan vokse uten å bli uoversiktlig.
Trenger du hjelp med Odoo-implementasjonen din?
I Dasolo bistår vi selskaper med å implementere, tilpasse og optimalisere Odoo. Enten dere bygger moduler fra bunnen av, legger til felter i standardmodeller eller feilsøker uventet datamodelloppførsel, har vi erfaringen som sparer tid og penger.
Har du spørsmål om datamodellen, feltstrategi eller teknisk implementering, tar vi gjerne en prat for å finne gode løsninger. Ta kontakt med oss så finner vi riktig tilnærming for ditt prosjekt.