Introduktion
När du börjar jobba med Odoo-utveckling stöter du snabbt på ett genomgående tema: arv. Odoo:s datamodell är byggd för att låta modeller återanvända och dela fält mellan varandra, så att man slipper duplicera information eller skriva upprepande kod.
I praktiken är ärvda fält navet i denna arkitektur. De gör det möjligt för en modell att visa och använda ett fält som faktiskt ligger sparat på en annan modell, vilket skapar en sömlös vy av samma data på flera ställen.
Denna guide går igenom vad som menas med ärvda fält, de tre sätt Odoo hanterar arv på, hur värden faktiskt lagras i databasen och hur du använder dessa mönster i kundanpassningar.
Vad är ett ärvt fält i Odoo?
I Odoo betraktas ett fält som ärvt när en modell får åtkomst till fält som definierats på en annan modell via något av arvsmönstren. I stället för att skapa ett nytt fält kopierar barnet åtkomsten och återanvänder källfältet.
Detta gör datamodellen kompakt och konsekvent. Ett fält som heter name på en partner är exakt samma värde som visas på offerter, kundkort och fakturor – olika modeller läser från samma ursprung.
Tre varianter av arv i Odoo
Odoo har tre grundläggande arvsmekanismer och varje variant påverkar fälten annorlunda.
1. Klassiskt arv
Det vanligaste sättet att utöka funktionalitet i Odoo: du använder _inherit utan att ange ett nytt _name. Det lägger till fält och metoder på befintlig modell utan att skapa någon ny databas-tabell. De nya fälten blir en del av den ursprungliga modellen.
Det är så standardmoduler breddar befintliga modeller. Till exempel lägger CRM ofta till fält på res.partner och dessa fält hamnar i samma partner-tabell som kärnfälten.
2. Prototype‑arv
När du anger både _inherit och _name skapar du en modell som börjar som en kopia av förälderns struktur men får egen tabell. Föräldrafälten dupliceras till den nya tabellen och förändringar i barnet påverkar inte föräldern.
Detta används inte lika ofta vid enkla anpassningar, men är praktiskt när du vill ha en ny modell som har samma struktur som en befintlig modell.
3. Delegations‑arv
Delegation använder _inherits och bygger en relation via en Many2one‑länk till föräldern. Barnmodellen exponerar föräldrafälten som om de vore egna, men själva dataposten ligger i förälderns tabell.
När utvecklare talar om ärvda fält i strikt mening menar de ofta detta: fältet dupliceras inte — det avläses genom relationen vid läs‑ och skrivtid.
Ett typiskt exempel i Odoo är kopplingen mellan res.users och res.partner: varje användare är också en partner, och kontaktuppgifter lagras på partnern men nås via användaren med delegations‑arv.
Hur fältet fungerar
Delegation i praktiken
När du använder _inherits sätter ORM:en upp en osynlig brygga mellan två tabeller. Vid läsning följer Odoo Many2one‑pekaren till förälderns rad och returnerar värdet från den tabellen.
Vid skrivning uppdateras förälderraden direkt. För utvecklaren känns fältet som ett normalt fält på barnet, men i databasen bor innehållet i föräldertabellen.
Det viktiga resultatet är att du undviker dataduplicering: ändrar du partnerns namn syns förändringen direkt överallt där partnern refereras, även på användarposten som ärvt fältet.
Klassiskt arv och databasen
Vid klassiskt arv hamnar nya fält i samma databas-tabell som den ursprungliga modellen. Det finns ingen separat tabell — den utökade modellen och originalet är identiska ur databasperspektiv. Detta är ofta den renaste vägen för enkla tillägg.
Relaterade fält som en lättviktig arvsliknande lösning
Ett related‑fält är en beräknad fälttyp som läser ett värde via en kedja av relationer. Det är inte samma sak som modell‑arv, men används frekvent för att visa värden från en annan modell utan att förändra modellens struktur.
Till exempel kan du lägga ett partner_country_id‑fält på en order som läser partner_id.country_id. Det beter sig som ett fält på ordern, men värdet kommer från partnern.
Related‑fält kan sparas i databasen med store=True, vilket gör sökningar snabbare men innebär mer lagring och behov av omberäkning när källdata förändras.
Hur fält bestäms i körning
När Odoo laddar en modell bygger det upp en fullständig karta över alla fält, inklusive ärvda sådana. Innan modellen används vet servern var varje fält hämtas ifrån — eget bord, föräldertabell via delegation eller en kedja av relationer. Denna upplösning sker vid uppstart och cachas för prestanda.
Affärsscenarier där ärvda fält hjälper
Ärvda fält är mer än ett tekniskt trick — de löser konkreta affärsproblem genom att hålla data konsekvent på flera ställen utan onödig kopiering.
1. CRM och försäljning: kontaktuppgifter
När en säljare skapar en lead hämtas kundens namn, telefon och e‑post via partnerlänken. Uppdateras partnerinformationen syns den direkt i alla leads, offerter och order som refererar partnern.
Detta är ett exempel där klassiskt arv och relaterade fält samverkar: CRM lägger till sina egna fält på res.partner och försäljningsvyn visar partnerns kontakt via related‑fält.
2. Produkter och varianter
Produktmodellen använder delegation för att hantera varianter: product.product ärvder product.template med _inherits. Gemensamma fält som namn, kategori och beskrivning ligger på templaten, medan variant‑specifika fält bor på variantposten.
Resultatet är att du kan ha många färgvarianter av samma tröja utan att lagra namn och beskrivning flera gånger.
3. Användare och kontakter
res.users använder _inherits = {'res.partner': 'partner_id'}, vilket innebär att en användare automatiskt har partnerns fält som namn, e‑post och telefon. Ändrar du medarbetarens e‑post uppdateras både användarkontot och kontaktkortet.
4. Lager: lagerrörelser och produktinfo
Lagerrader visar produktbeskrivningar som hämtas via relationer till produkttemplaten. Lageransvariga får alltid aktuell produktinformation utan att inventarie‑modulen duplicerar data.
5. Redovisning: fakturarader
Fakturarader visar produktnamn, konton och skatter som läses från produkt‑ och partnermodeller via relationer. Ekonomer ser samma data som säljavdelningen konfigurerat, eftersom värdena kommer från samma källa.
Skapa eller anpassa ärvda fält
Använda Odoo Studio
Odoo Studio är gränssnittet för no‑code‑anpassningar. Från Studio kan du lägga till fält på modeller utan Python — under huven skapar Studio klassiskt arv genom att utöka modellens definition.
Studio låter dig också skapa relaterade fält. Väljer du "Related Field" pekar fältet på en relationell väg från den aktuella modellen, till exempel att läsa kundens land eller VAT‑nummer direkt från partnern.
För många funktionella användare och konsulter är Studio bäst: det hanterar fältnamn, databasmigration och vyplacering automatiskt.
Tekniska anpassningar med Python
För utvecklare definieras ärvda fält i Python med models.Model från Odoo ORM.
Exempel på klassiskt arv för att lägga till ett anpassat fält på en befintlig modell:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Beräknat kontraktsvärde'
)
Exempel på delegation 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='Medarbetare'
)
Exempel på related‑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)
Det går också att skapa fält programmässigt via Odoo:s XML‑RPC och modellen ir.model.fields. Det är samma sak som vad Studio gör och passar när du vill skapa fält utan direkt serveråtkomst.
För att lägga till ett related‑fält via API skapar du en ir.model.fields‑post med rätt ttype och anger related‑vägen. Metoden lämpar sig väl för automatiserade driftsättningar.
Rekommenderade arbetssätt
Välj rätt arvstyp för uppgiften
Använd klassiskt arv när du bara vill lägga till fält eller metoder på en befintlig modell — det är enkelt och det vanligaste. Reserviera delegation när du behöver två separata entiteter som är relaterade men ändå måste ha egna poster och livscykler.
Föredra related‑fält för läsbehov
Om du bara behöver visa ett värde från en kopplad post är ett related‑fält ofta renare än delegation. Det introducerar inte en ny beroendesstruktur och är lättare att förstå och underhålla.
Var försiktig med store=True på related‑fält
Att spara ett related‑fält i databasen ökar sök‑ och filterhastighet, men betyder också att värdet är en kopia. Odoo beräknar om vid ändring, men i vissa edge‑cases kan synkproblem uppstå. Spara endast när du verkligen behöver filtrera eller sortera mycket på fältet.
Prefixa alltid egna fält med x_
Alla anpassade fält som läggs till standardmodeller bör börja med x_ (eller använda modul‑namnrymden). Det minskar risken för fältnamnskonflikter vid framtida Odoo‑uppgraderingar.
Dokumentera ditt arvsspår
Vid komplexa anpassningar skriv gärna korta kommentarer eller designnoter som förklarar varifrån ett fält hämtas och varför. Ett fält som x_country_code på en order kanske egentligen pekar på partner_id.country_id.code – utan dokumentation blir det svårt att förstå senare.
Hantera kaskad‑raderingar korrekt
Vid delegation skapas förälderraden när barnet skapas. När barnet tas bort bör ofta föräldern också tas bort. Använd ondelete='cascade' på Many2one‑fältet i _inherits för att undvika lämnade huvor (orphan records).
Vanliga fallgropar
Förväxla inte arvstyperna
Vanligt misstag är att kombinera _inherit med _name när man menade klassisk extension — det skapar en helt ny modell i stället för att utöka en befintlig. Kolla alltid din modelldefinition: om du inte vill skapa en ny modell, utelämna _name.
Glöm inte att skapa förälderraden vid _inherits
Vid delegation skapas inte alltid förälderraden automatiskt i alla scenarier. Vid programmatisk skapning via API måste du antingen låta ORM hantera det (normalt fungerar create()) eller skapa föräldern först och skicka dess id. Hoppar du över detta får du constraint‑fel.
Försök inte ändra fälttyp genom arv
Odoo tillåter inte att du ändrar typen på ett befintligt fält genom arv. Du kan ändra etikett, domän eller hjälptext men inte byta Char till Integer. Försök att göra det leder till fel vid modulinstallation.
Överanvändning av lagrade related‑fält
Att sätta store=True på alla related‑fält frestar för prestandan, men ökar databasen och underhållsbehovet. Om källfältet ändras ofta orsakar det mycket omberäkning. Använd lagrade related‑fält selektivt när det finns ett verkligt behov.
Anta inte att accessregler följer med barnet
Fält som ärvts via delegation ligger på föräldermodellen. Åtkomsträttigheter definierade på barnet gäller inte automatiskt för föräldern på databasenivå. Om du begränsar åtkomsten till barnet men inte till föräldern kan användare fortfarande läsa värden via föräldern. Granska alltid säkerhetsregler för båda modellerna vid delegation.
Sammanfattning
Ärvda fält är en grundläggande del av Odoo‑arkitekturen. Kopplingarna mellan användare och kontakter, mellan produktvarianter och templates, eller mellan order och kunddata bygger på denna princip för att hålla information konsistent och undvika duplicering.
När du vet vilken arvstyp som passar, när du bör använda ett related‑fält och hur allt ligger i databasen blir du en mer effektiv Odoo‑anpassare. Du skriver renare kod, skapar bättre datamodeller och slipper många tidskrävande felsökningar.
Huvudpoängen är enkel: Odoo designar för att data ska bo på ett ställe men vara åtkomligt från många. Det är kärnan i ärvda fält och anledningen till att systemet håller sig samman även när moduler multipliceras.
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 egen modul, lägger till fält på standardmodeller eller utreder varför datamodellen beter sig oväntat, har vårt team praktisk erfarenhet för att snabba upp projektet och undvika dyra misstag.
Har du frågor om din Odoo‑datamodell, strategi för anpassade fält eller teknisk implementation? Vi tar gärna ett samtal och går igenom din situation. Kontakta oss så hittar vi rätt tillvägagångssätt för ditt projekt.