Introduktion
När du börjar arbeta med Odoo-utveckling dyker ett koncept upp gång på gång: arv. Odoos ORM är byggt kring idén att modeller kan utöka, dela och återanvända varandras fält utan att duplicera data eller skriva redundant kod.
Ärvda fält är centrala för detta system. De är hur Odoo låter en modell transparent få tillgång till och exponera fält som fysiskt definieras och lagras på en annan modell. När du förstår denna mekanism börjar många saker i Odoo-datamodellen att ge mening.
Denna guide förklarar vad ärvda fält är, de tre typerna av modellärv som producerar dem, hur de beter sig i databasen och hur du kan använda dem i verkliga Odoo-anpassningsprojekt.
Vad är ett ärvt fält i Odoo?
I Odoos ORM-ramverk betraktas ett fält som ärvs när en modell får tillgång till fält som definierats på en annan modell genom en av de tre stödda arvsmekanismerna. Istället för att omdefiniera dessa fält från grunden återanvänder barnmodellen helt enkelt dem.
Detta är en del av vad som gör Odoo-datamodellen så kompakt och konsekvent. Det samma name-fältet på en partnerpost är det som visas på försäljningsorder, CRM-leads och fakturor, eftersom alla dessa modeller så småningom läser från samma källa.
De Tre Typerna av Arv i Odoo
Odoo stöder tre distinkta typer av modellärv, och var och en hanterar fält på olika sätt.
1. Klassiskt Arv
Detta är det vanligaste mönstret inom Odoo-utveckling. Du använder _inherit utan att definiera ett nytt _name. Detta utökar en befintlig modell direkt, genom att lägga till nya fält eller metoder till den. Ingen ny databas-tabell skapas. De nya fälten visas helt enkelt på den ursprungliga modellen.
Så här lägger de flesta Odoo-moduler till fält till standardmodeller. Om du installerar CRM-modulen lägger den till fält till res.partner genom klassiskt arv. Dessa fält lagras i partner-tabellen tillsammans med kärnfälten.
2. Prototyp Arv
Detta är när du kombinerar _inherit och _name tillsammans. Den nya modellen börjar som en kopia av föräldermodellens struktur, men får sin egen databas-tabell. Alla föräldrafält dupliceras till den nya modellen. Ändringar i barnmodellen påverkar inte föräldern.
Detta mönster är mindre vanligt i vardaglig anpassning men används för att skapa helt nya modeller som delar strukturen av en befintlig.
3. Delegation Arv
Detta är den mest distinkta typen, definierad med _inherits. Barnmodellen länkar till en föräldermodell genom ett Many2one-fält. Barnmodellen exponerar sedan alla fält från föräldern som om de vore sina egna. Data finns i förälderns tabell, inte barnets tabell.
Detta är vad de flesta utvecklare menar när de pratar om ärvda fält i strikt mening. Fälten dupliceras inte. De nås genom den relationella länken vid läs- och skrivtid.
Det mest kända exemplet i standard Odoo är relationen mellan res.users och res.partner. Varje användare är också en partner. Användarens namn, e-postadress och telefonnummer lagras på partnerposten och nås av användaren genom delegationsarv.
Hur fältet fungerar
Delegationsarv Under Huvan
När en modell använder _inherits skapar Odoos ORM en transparent bro mellan två databas-tabeller. När du läser ett ärvt fält på barnposten följer Odoo automatiskt Many2one-länken till föräldraposten och returnerar värdet som lagras där.
När du skriver till ett ärvt fält från barnmodellen skriver Odoo direkt till föräldraposten. Ur utvecklarens perspektiv känns fältet inbyggt. Ur databasens perspektiv lever datan i föräldratabellen.
Detta har en viktig konsekvens: det finns ingen dataduplicering. Om du uppdaterar en partners namn, återspeglas den förändringen omedelbart överallt där partnern refereras, inklusive på användarposten som ärver från den.
Klassiskt Arv och Databasen
Med klassiskt arv läggs nya fält till i den ursprungliga modellens databas-tabell. Det finns ingen andra tabell involverad. Den utvidgade modellen och den ursprungliga modellen är samma sak i databasen. Detta är det renaste och vanligaste sättet att lägga till fält i Odoo-anpassningsprojekt.
Relaterade Fält som Lättviktsarv
Ett related fält är en speciell typ av beräknat fält i Odoo ORM som läser ett värde från en länkad post genom en kedja av relationella fält. Det är inte strikt detsamma som modellärv, men det används ofta för att visa ärvda datastil på en modell utan att modifiera modellens struktur.
Till exempel kan du definiera ett partner_country_id fält på en försäljningsorder som läser partner_id.country_id. Fältet beter sig som ett inbyggt fält på försäljningsordern, men värdet kommer från partnern.
Relaterade fält kan valfritt lagras i databasen med store=True, vilket förbättrar sök- och filtreringsprestanda men lägger till lagringsöverhuvud och kräver omberäkning när källan ändras.
Hur fält löses vid körning
När Odoo laddar en modelldefinition, löser den hela fältkartan, inklusive alla ärvda fält. Vid den tidpunkt då en modell är redo att användas har Odoo redan kopplat varje tillgängligt fält till sin källa, oavsett om den källan är modellens egen tabell, en förälder-tabell via delegering, eller en relaterad kedja. Denna lösning sker en gång vid serverstart och cachas för prestanda.
Affärsanvändningsfall
Ärvda fält är inte bara ett tekniskt koncept. De löser verkliga affärsproblem genom att hålla data konsekvent över olika delar av Odoo utan duplicering.
1. CRM och Försäljning: Kontaktinformation
När en säljare skapar en lead i CRM-modulen kommer kundens namn, telefonnummer och e-postadress från partnerposten via en Many2one-länk. Om partnerns uppgifter ändras, återspeglar varje lead, offert och order kopplad till den partnern uppdateringen omedelbart.
Detta är klassisk arv och relaterade fält som arbetar tillsammans. CRM-modulen utökar res.partner med CRM-specifika fält (som leadantal och möjlighetsstadium), och försäljningsorder visar partnerkontaktinformation genom relaterade fält.
2. Produkter och varianter
Odoos produktmodell använder delegeringsarv för att hantera produktvarianter på ett rent sätt. Modellen product.product (en specifik variant) använder _inherits för att länka till product.template. Fält som delas över alla varianter, såsom produktnamn, kategori, försäljningspris och beskrivning, finns på mallen. Variant-specifika fält som streckkod eller intern referens finns på variantposten själv.
Denna design innebär att du kan ha 50 färgvarianter av en skjorta, alla som delar samma namn och beskrivning, utan att lagra dessa värden 50 gånger i databasen.
3. Användare och Partner
Varje Odoo-användare är också en kontakt. Modellen res.users använder _inherits = {'res.partner': 'partner_id'}, vilket innebär att användaren automatiskt ärver alla partnerfält inklusive namn, e-post, telefon, adress och profilbild. När du uppdaterar en anställds e-postadress, uppdateras den både i användarinställningarna och i kontaktboken samtidigt.
4. Lager: Lagerflyttningar och produktinformation
Lagerflyttningslinjer i lagerhanteringsmodulen visar produktbeskrivningar som kommer från produktmallen genom en kedja av relaterade fält. Lagerchefer ser korrekt, uppdaterad produktinformation direkt i sina plocklistor utan att lagerhanteringsmodulen behöver duplicera produktdata.
5. Redovisning: Fakturalinjer
Redovisningsflyttningslinjer refererar till produkter och partners. Produktnamnet, kontokoderna och skatteinställningarna som visas på en fakturalinje hämtas från produkt- och partnermodellerna genom relationella länkar och relaterade fält. Redovisningsekonomer ser konsekvent data som matchar vad försäljningsteamen konfigurerade på produkten, eftersom de läser från samma källa.
Skapa eller anpassa ärvda fält
Använda Odoo Studio
Odoo Studio är det kodfria gränssnittet för att anpassa Odoo-modeller och vyer. Från Studio kan du lägga till nya fält till vilken modell som helst utan att skriva Python-kod. Vad Studio gör under huven är klassisk arv: det utökar modellen genom att lägga till ett nytt fält till dess definition.
Studio låter dig också skapa relaterade fält. När du väljer "Relaterat fält" som fälttyp kan du peka på vilket fält som helst som är tillgängligt genom en relationell kedja från den aktuella modellen. Till exempel, på försäljningsordermodellen kan du skapa ett relaterat fält som läser kundens land eller momsnummer direkt från partnerposten.
För de flesta affärsanvändare och funktionella konsulter är Studio rätt verktyg för att lägga till fält till Odoo. Det hanterar fältnamn, databasflyttning och vyplacering automatiskt.
Teknisk anpassning med Python
För utvecklare som bygger Odoo-moduler definieras ärvda fält i Python med hjälp av models.Model-klassen från Odoo ORM.
Klassisk arv för att lägga till ett anpassat fält till en befintlig modell:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Estimated Contract Value'
)Delegationsarv för att skapa en ny modell som delar fält från en befintlig:
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'
)Relaterade fält för att visa ett värde från en länkad 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 (Fjärrkonfiguration)
Fält kan också läggas till programmässigt med Odoo's XML-RPC API och modellen ir.model.fields. Detta är tillvägagångssättet som används i Dasolos fjärrkonfigurationsnotebooks. Det är ekvivalent med vad Studio gör, och det möjliggör fält skapande utan direkt serveråtkomst.
För att lägga till ett relaterat fält via API:et skapar du en ir.model.fields post med ttype='many2one' (eller den lämpliga typen) och sätter related parametern för att definiera den relationella vägen. Detta tillvägagångssätt är väl lämpat för att distribuera anpassade fält som en del av en automatiserad installationsprocess.
Bästa praxis
Välj rätt arvstyp för jobbet
Använd klassiskt arv när du helt enkelt vill lägga till fält eller metoder till en befintlig modell. Det är det enklaste tillvägagångssättet och är vad den stora majoriteten av Odoo-moduler använder. Reservera delegationsarv för fall där du verkligen behöver två separata postuppsättningar länkade tillsammans, som när ett affärskoncept utökar en kontakt utan att vara en kontakt själv.
Föredra relaterade fält för läsåtkomst
Om du bara behöver visa ett värde från en länkad post i ett formulär eller listvy, är ett relaterat fält renare än delegationsarv. Det undviker att skapa ett nytt strukturellt beroende och är lätt att förstå och underhålla.
Var försiktig med store=True på relaterade fält
Att lagra ett relaterat fält i databasen snabbar upp sökningar och filter, men det betyder att värdet är en kopia. Odoo utlöser omberäkning när källan ändras, men i kantfall kan detta bli osynkat. Lagra endast relaterade fält när du verkligen behöver filtrera eller sortera efter dem i stor skala.
Prefixa alltid anpassade fält med x_
Alla fält du lägger till en standard Odoo-modell genom arv bör börja med x_ (eller använda ett modulnamn i en korrekt modul). Detta förhindrar konflikter med fält som läggs till av Odoo i framtida versioner.
Dokumentera din arvkedja
När du arbetar med komplexa anpassningar, skriv en kort kommentar eller designanteckning som förklarar var fälten kommer ifrån och varför. Ett fält som heter x_country_code på en försäljningsorder kanske inte uppenbart kopplar tillbaka till partner_id.country_id.code utan dokumentation.
Hantera kaskadborttagningar korrekt
Vid delegationsarv skapas föräldra-posten automatiskt när barnet skapas. När barnet tas bort bör föräldern vanligtvis också tas bort. Ställ in ondelete='cascade' på Many2one i _inherits för att säkerställa ren borttagning utan föräldralösa poster.
Vanliga fallgropar
Förvirra de tre arvstyperna
Det vanligaste misstaget för utvecklare som är nya inom Odoo är att använda _inherit med _name när de avsåg klassisk utvidgning. Detta skapar av misstag en helt ny modell istället för att utöka den befintliga. Dubbelkolla din modelldefinition: om du inte avser att skapa en ny modell, utelämna _name.
Glömma att skapa föräldraposten i _inherits
Med delegationsarv skapar inte föräldraposten sig själv automatiskt i alla scenarier. När du skapar en barnpost programmässigt via API:et eller i ett skript, måste du antingen låta Odos ORM hantera skapandet av föräldern (vilket det gör när du använder create normalt) eller skapa föräldraposten först och skicka dess ID. Att hoppa över detta steg resulterar i ett databasbegränsningsfel.
Försöka ändra en fälts typ genom arv
Odoo tillåter inte att ändra typen av ett befintligt fält via arv. Du kan ändra attribut som strängetikett, domän eller hjälptext, men du kan inte ändra ett Char-fält till ett Integer-fält. Att försöka detta kommer att orsaka ett fel vid modulinstallation.
Överanvändning av lagrade relaterade fält
Att lägga till store=True på varje relaterat fält är frestande av prestandaskäl, men det ökar databasens storlek och introducerar underhållskostnader. Om källfältet ändras ofta, utlöser lagrade relaterade fält mycket omberäkning. Använd lagrade relaterade fält selektivt, endast när du har ett konkret behov av att filtrera eller gruppera efter dem i stora dataset.
Anta att ärvda fält respekterar barnmodellens åtkomsträttigheter
Fält som ärvts via delegering finns på föräldermodellen. Åtkomsträttigheter som definieras på barnmodellen tillämpas inte automatiskt på dessa fält på databasnivå. Om du begränsar åtkomst till barnmodellen men inte föräldern, kan användare fortfarande läsa de ärvda fältvärdena direkt genom föräldermodellen. Granska alltid säkerhetsreglerna för båda modellerna när du använder delegerad arv.
Slutsats
Ärvda fält är inte en nischfunktion inom Odoo-utveckling. De är inbakade i systemets arkitektur. Förhållandet mellan användare och partners, mellan produktvarianter och mallar, mellan försäljningsorder och kundkontaktinformation: allt detta bygger på fältarv för att hålla data konsekvent och undvika duplicering.
Att förstå vilken arvtyp som ska användas, när man ska använda ett relaterat fält istället, och hur dessa mekanismer beter sig i databasen kommer att göra dig till en betydligt mer effektiv Odoo-anpassare. Du kommer att skriva renare kod, designa bättre datamodeller och spendera mindre tid på att felsöka oväntat fältbeteende.
Huvudpoängen är enkel: Odoos ORM är utformat så att fält finns på ett ställe och nås från många. Detta är principen bakom ärvda fält, och det är vad som håller Odoos datamodell sammanhängande även när den växer över dussintals sammanlänkade moduler.
Behöver du hjälp med din Odoo-implementering?
På Dasolo hjälper vi företag att implementera, anpassa och optimera Odoo. Oavsett om du bygger en anpassad modul från grunden, utökar standardmodeller med nya fält, eller försöker förstå varför din datamodell beter sig på oväntade sätt, har vårt team den praktiska Odoo-erfarenheten för att hjälpa dig att gå snabbare och undvika kostsamma misstag.
Om du har frågor om din Odoo-datamodell, strategi för anpassade fält eller teknisk implementering, skulle vi gärna prata igenom din situation. Kontakta oss och låt oss hitta rätt tillvägagångssätt för ditt projekt.