Introduksjon
Når du begynner å jobbe med Odoo-utvikling, dukker et konsept opp igjen og igjen: arv. Odoos ORM er bygget rundt ideen om at modeller kan utvide, dele og gjenbruke hverandres felt uten å duplisere data eller skrive overflødig kode.
Arvede felt er sentrale i dette systemet. De er hvordan Odoo lar en modell få tilgang til og eksponere felt som fysisk er definert og lagret på en annen modell. Når du forstår denne mekanismen, begynner mange ting i Odoo-datamodellen å gi mening.
Denne guiden forklarer hva arvede felt er, de tre typene modellarv som produserer dem, hvordan de oppfører seg i databasen, og hvordan du kan bruke dem i ekte Odoo-tilpasningsprosjekter.
Hva er et arvet felt i Odoo?
I Odoos ORM-rammeverk anses et felt som arvet når en modell får tilgang til felt definert på en annen modell gjennom en av de tre støttede arve-mekanismene. I stedet for å redefinere disse feltene fra bunnen av, gjenbruker barne-modellen dem enkelt.
Dette er en del av hva som gjør Odoo-datamodellen så kompakt og konsistent. Det samme name-feltet på en partnerpost er det som vises på salgsordrer, CRM-leads og fakturaer, fordi alle disse modellene til slutt leser fra den samme kilden.
De tre typene arv i Odoo
Odoo støtter tre distinkte typer modellarv, og hver av dem håndterer feltene forskjellig.
1. Klassisk arv
Dette er det vanligste mønsteret i Odoo-utvikling. Du bruker _inherit uten å definere et nytt _name. Dette utvider en eksisterende modell direkte, og legger til nye felt eller metoder til den. Ingen ny databasetabell opprettes. De nye feltene vises enkelt på den originale modellen.
Slik legger de fleste Odoo-moduler til felt i standardmodeller. Hvis du installerer CRM-modulen, legger den til felt i res.partner gjennom klassisk arv. Disse feltene lagres i partner-tabellen sammen med kjernefeltene.
2. Prototype-arv
Dette er når du kombinerer _inherit og _name sammen. Den nye modellen starter som en kopi av foreldremodellens struktur, men får sin egen databasetabell. Alle foreldrefeltene dupliseres inn i den nye modellen. Endringer i barne-modellen påvirker ikke forelderen.
Dette mønsteret er mindre vanlig i hverdags-tilpasning, men brukes til å lage helt nye modeller som deler strukturen til en eksisterende.
3. Delegasjonsarv
Dette er den mest distinkte typen, definert ved hjelp av _inherits. Barne-modellen kobles til en foreldremodell gjennom et Many2one-felt. Barne-modellen eksponerer deretter alle feltene til forelderen som om de var egne. Dataene lever i foreldrenes tabell, ikke barne-tabellen.
Dette er hva de fleste utviklere mener når de snakker om arvede felt i streng forstand. Feltene er ikke duplisert. De blir aksessert gjennom den relasjonelle linken ved lesing og skriving.
Det mest kjente eksempelet i standard Odoo er forholdet mellom res.users og res.partner. Hver bruker er også en partner. Brukerens navn, e-post og telefonnummer lagres på partnerposten og aksesseres av brukeren gjennom delegasjonsarv.
Hvordan feltet fungerer
Delegasjonsarv Under Panseret
Når en modell bruker _inherits, oppretter Odoo's ORM en gjennomsiktig bro mellom to databastabeller. Når du leser et arvet felt på barnemodellen, følger Odoo automatisk Many2one-lenken til foreldremodellen og returnerer verdien som er lagret der.
Når du skriver til et arvet felt fra barnemodellen, skriver Odoo direkte til foreldremodellen. Fra utviklerens perspektiv føles feltet innfødt. Fra databasens perspektiv lever dataene i foreldretabellen.
Dette har en viktig konsekvens: det er ingen dataduplisering. Hvis du oppdaterer navnet til en partner, reflekteres den endringen umiddelbart overalt hvor partneren er referert, inkludert på brukerposten som arver fra den.
Klassisk Arv og Databasen
Med klassisk arv legges nye felt til den originale modellens databastabell. Det er ingen andre tabeller involvert. Den utvidede modellen og den originale modellen er det samme i databasen. Dette er den reneste og mest vanlige måten å legge til felt i Odoo-tilpasningsprosjekter.
Relaterte Felt som Lettvektsarv
Et related felt er en spesiell type beregnet felt i Odoo ORM som leser en verdi fra en koblet post gjennom en kjede av relasjonelle felt. Det er ikke strengt det samme som modellarv, men det brukes ofte for å vise arvet-stil data på en modell uten å endre modellens struktur.
For eksempel kan du definere et partner_country_id felt på en salgsordre som leser partner_id.country_id. Feltet oppfører seg som et innfødt felt på salgsordren, men verdien kommer fra partneren.
Relaterte felt kan valgfritt lagres i databasen med store=True, noe som forbedrer søke- og filterytelsen, men legger til lagringsoverhead og krever rekalkulering når kilden endres.
Hvordan felt blir løst ved kjøring
Når Odoo laster en modelldefinisjon, løser den det komplette feltkartet, inkludert alle arvede felt. Innen modellen er klar til bruk, har Odoo allerede kartlagt hvert tilgjengelig felt til sin kilde, enten den kilden er modellens egen tabell, en foreldretabell via delegasjon, eller en relatert kjede. Denne oppløsningen skjer én gang ved serveroppstart og blir hurtigbufret for ytelse.
Forretningsbrukstilfeller
Arvede felt er ikke bare et teknisk konsept. De løser reelle forretningsproblemer ved å holde data konsistente på tvers av forskjellige deler av Odoo uten duplisering.
1. CRM og salg: Kontaktinformasjon
Når en selger oppretter et lead i CRM-modulen, kommer kundenavn, telefonnummer og e-postadresse fra partnerposten via en Many2one-lenke. Hvis partnerens detaljer endres, reflekterer hvert lead, tilbud og ordre knyttet til den partneren oppdateringen umiddelbart.
Dette er klassisk arv og relaterte felt som jobber sammen. CRM-modulen utvider res.partner med CRM-spesifikke felt (som leadantall og mulighetsstadium), og salgsordrer viser partnerens kontaktinformasjon gjennom relaterte felt.
2. Produkter og varianter
Odoos produktmodell bruker delegasjonsarv for å håndtere produktvarianter på en ryddig måte. product.product-modellen (en spesifikk variant) bruker _inherits for å knytte seg til product.template. Felt som deles på tvers av alle varianter, som produktnavn, kategori, salgspris og beskrivelse, finnes på malen. Variant-spesifikke felt som strekkode eller intern referanse finnes på variantposten selv.
Dette designet betyr at du kan ha 50 fargevarianter av en skjorte, alle som deler samme navn og beskrivelse, uten å lagre disse verdiene 50 ganger i databasen.
3. Brukere og partnere
Hver Odoo-bruker er også en kontakt. res.users-modellen bruker _inherits = {'res.partner': 'partner_id'}, noe som betyr at brukeren automatisk arver alle partnerfelt inkludert navn, e-post, telefon, adresse og profilbilde. Når du oppdaterer en ansatts e-postadresse, oppdateres den både i brukerinnstillingene og i kontaktboken samtidig.
4. Lager: Lagerbevegelser og produktinformasjon
Lagerbevegelseslinjer i Inventarmodulen viser produktbeskrivelser som kommer fra produkttemplatet gjennom en kjede av relaterte felt. Lagerledere ser nøyaktig, oppdatert produktinformasjon direkte i plukklister uten at inventarmodulen trenger å duplisere produktdata.
5. Regnskap: Fakturalinjer
Regnskapsbevegelseslinjer refererer til produkter og partnere. Produktnavnet, kontokodene og skattekonfigurasjonene som vises på en fakturalinje, hentes fra produkt- og partnermodeller gjennom relasjonelle lenker og relaterte felt. Regnskapsførere ser konsistente data som samsvarer med det salgsteamene har konfigurert på produktet, fordi de leser fra samme kilde.
Opprette eller tilpasse arvede felt
Bruke Odoo Studio
Odoo Studio er grensesnittet uten kode for tilpasning av Odoo-modeller og -visninger. Fra Studio kan du legge til nye felt til enhver modell uten å skrive Python-kode. Hva Studio gjør under panseret er klassisk arv: det utvider modellen ved å legge til et nytt felt til definisjonen.
Studio lar deg også opprette relaterte felt. Når du velger "Relatert felt" som felttype, kan du peke på ethvert felt som er tilgjengelig gjennom en relasjonell kjede fra den nåværende modellen. For eksempel, på salgsordremodellen kan du opprette et relatert felt som leser kundens land eller MVA-nummer direkte fra partnerposten.
For de fleste forretningsbrukere og funksjonelle konsulenter er Studio det rette verktøyet for å legge til felt til Odoo. Det håndterer feltnavn, databasemigrasjon og visningsplassering automatisk.
Teknisk tilpasning med Python
For utviklere som bygger Odoo-moduler, defineres arvede felt i Python ved hjelp av models.Model-klassen fra Odoo ORM.
Klassisk arv for å legge til et tilpasset felt til en eksisterende modell:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Estimert kontraktsverdi'
)Delegasjonsarv for å opprette en ny modell som deler felt fra en eksisterende:
class EmployeeProfile(models.Model):
_name = 'hr.employee.profile'
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one(
'res.partner',
required=True,
ondelete='cascade'
)
employee_id = fields.Many2one(
'hr.employee',
string='Employee'
)Relaterte felt for å hente en verdi fra en koblet post:
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Kundens land',
store=True
)Via XML-RPC API (Fjernkonfigurasjon)
Felt kan også legges til programmatisk ved hjelp av Odoo's XML-RPC API og ir.model.fields modellen. Dette er tilnærmingen som brukes i Dasolo's fjernkonfigurasjonsnotater. Det er ekvivalent med det Studio gjør, og det tillater feltopprettelse uten direkte servertilgang.
For å legge til et relatert felt via API-en, oppretter du en ir.model.fields post med ttype='many2one' (eller den passende typen) og setter related parameteren for å definere den relasjonelle banen. Denne tilnærmingen er godt egnet for å distribuere tilpassede felt som en del av en automatisert oppsettprosess.
Beste praksis
Velg riktig arvtype for jobben
Bruk klassisk arv når du bare vil legge til felt eller metoder til en eksisterende modell. Det er den enkleste tilnærmingen og er hva det store flertallet av Odoo-moduler bruker. Reserver delegasjonsarv for tilfeller der du virkelig trenger to separate postsett som er koblet sammen, for eksempel når et forretningskonsept utvider en kontakt uten å være en kontakt selv.
Foretrekk relaterte felt for leseaksess
Hvis du bare trenger å vise en verdi fra en koblet post på et skjema eller listevisning, er et relatert felt renere enn delegasjonsarv. Det unngår å opprette en ny strukturell avhengighet og er lett å forstå og vedlikeholde.
Vær forsiktig med store=True på relaterte felt
Å lagre et relatert felt i databasen akselererer søk og filtre, men det betyr at verdien er en kopi. Odoo utløser rekalkulering når kilden endres, men i kanttilfeller kan dette bli ute av synk. Lagre bare relaterte felt når du virkelig trenger å filtrere eller sortere etter dem i stor skala.
Alltid prefiks tilpassede felt med x_
Ethvert felt du legger til en standard Odoo-modell gjennom arv, bør starte med x_ (eller bruke et modulnavnrom i en riktig modul). Dette forhindrer konflikter med felt lagt til av Odoo i fremtidige versjoner.
Dokumenter din arvkjede
Når du jobber med komplekse tilpasninger, skriv en kort kommentar eller designnotat som forklarer hvor feltene kommer fra og hvorfor. Et felt kalt x_country_code på en salgsordre kan ikke åpenbart knyttes tilbake til partner_id.country_id.code uten dokumentasjon.
Håndter kaskade-slettinger korrekt
I delegasjonsarv opprettes foreldrecordet automatisk når barnet opprettes. Når barnet slettes, bør forelderen vanligvis også slettes. Sett ondelete='cascade' på Many2one i _inherits for å sikre ren sletting uten foreldreløse poster.
Vanlige fallgruver
Forveksling av de tre arvtypene
Den vanligste feilen for utviklere som er nye i Odoo, er å bruke _inherit med _name når de mente klassisk utvidelse. Dette oppretter ved en feiltakelse en helt ny modell i stedet for å utvide den eksisterende. Dobbeltsjekk modelldefinisjonen din: hvis du ikke har til hensikt å opprette en ny modell, utelat _name.
Glemme å opprette foreldrecordet i _inherits
Med delegasjonsarv oppretter ikke foreldrecordet seg selv automatisk i alle scenarier. Når du oppretter en barnepost programmatisk via API eller i et skript, må du enten la Odoos ORM håndtere foreldres opprettelse (som det gjør når du bruker create normalt) eller opprette foreldrecordet først og sende ID-en. Å hoppe over dette trinnet resulterer i en databasebegrensningsfeil.
Prøve å endre en felttype gjennom arv
Odoo tillater ikke å overstyre typen til et eksisterende felt via arv. Du kan endre attributter som strengenavn, domene eller hjelpetekst, men du kan ikke endre et Char-felt til et Integer-felt. Å forsøke dette vil føre til en feilmelding ved modulinstallasjon.
Overforbruk av lagrede relaterte felt
Å legge til store=True på hvert relaterte felt er fristende av ytelsesgrunner, men det øker databasestørrelsen og introduserer vedlikeholdsbelastning. Hvis kildefeltet endres ofte, utløser lagrede relaterte felt mye rekalkulering. Bruk lagrede relaterte felt selektivt, kun når du har et konkret behov for å filtrere eller gruppere etter dem i store datasett.
Antar at arvede felt respekterer tilgangsregler for barne-modeller
Felt arvet via delegasjon lever på foreldremodellen. Tilgangsrettigheter definert på barne-modellen gjelder ikke automatisk for disse feltene på databasens nivå. Hvis du begrenser tilgangen til barne-modellen, men ikke foreldremodellen, kan brukere fortsatt lese verdiene til de arvede feltene direkte gjennom foreldremodellen. Gå alltid gjennom sikkerhetsregler for begge modeller når du bruker delegasjonsarv.
Konklusjon
Arvede felt er ikke en nisje-funksjon i Odoo-utvikling. De er integrert i arkitekturen til systemet. Forholdet mellom brukere og partnere, mellom produktvarianter og maler, mellom salgsordrer og kundekontaktinformasjon: alt dette er avhengig av feltarv for å holde data konsistente og unngå duplisering.
Å forstå hvilken arvtype som skal brukes, når man skal bruke et relatert felt i stedet, og hvordan disse mekanismene oppfører seg i databasen, vil gjøre deg til en betydelig mer effektiv Odoo-tilpasser. Du vil skrive renere kode, designe bedre datamodeller, og bruke mindre tid på å feilsøke uventet feltoppførsel.
Hovedpoenget er enkelt: Odoos ORM er designet slik at felt lever på ett sted og blir aksessert fra mange. Dette er prinsippet bak arvede felt, og det er det som holder Odoos datamodell sammenhengende selv når den vokser på tvers av dusinvis av sammenkoblede moduler.
Trenger du hjelp med Odoo-implementeringen din?
Hos Dasolo hjelper vi selskaper med å implementere, tilpasse og optimalisere Odoo. Enten du bygger en tilpasset modul fra bunnen av, utvider standardmodeller med nye felt, eller prøver å forstå hvorfor datamodellen din oppfører seg på uventede måter, har teamet vårt den praktiske Odoo-erfaringen som kan hjelpe deg å bevege deg raskere og unngå kostbare feil.
Hvis du har spørsmål om datamodellen din i Odoo, strategi for tilpassede felt eller teknisk implementering, vil vi gjerne snakke gjennom situasjonen din. Ta kontakt med oss og la oss finne den rette tilnærmingen for prosjektet ditt.