Inleiding
Wanneer u begint met Odoo-ontwikkeling, komt er één concept keer op keer naar voren: erfelijkheid. Odoo's ORM is gebouwd rond het idee dat modellen elkaars velden kunnen uitbreiden, delen en hergebruiken zonder gegevens te dupliceren of overbodige code te schrijven.
Geërfde velden zijn centraal in dit systeem. Ze zijn hoe Odoo een model in staat stelt om transparant toegang te krijgen tot en velden bloot te stellen die fysiek zijn gedefinieerd en opgeslagen op een ander model. Zodra u dit mechanisme begrijpt, beginnen veel dingen in het Odoo-datamodel logisch te worden.
Deze gids legt uit wat geërfde velden zijn, de drie types modelerfelijkheid die ze produceren, hoe ze zich in de database gedragen en hoe u ze kunt gebruiken in echte Odoo-aanpassingsprojecten.
Wat is een geërfd veld in Odoo?
In Odoo's ORM-framework wordt een veld als geërfd beschouwd wanneer een model toegang krijgt tot velden die zijn gedefinieerd op een ander model via een van de drie ondersteunde erfmechanismen. In plaats van die velden vanaf nul opnieuw te definiëren, hergebruikt het kindmodel ze eenvoudig.
Dit is een deel van wat het Odoo-datamodel zo compact en consistent maakt. Hetzelfde name veld op een partnerrecord is degene die verschijnt op verkooporders, CRM-leads en facturen, omdat al deze modellen uiteindelijk uit dezelfde bron lezen.
De Drie Soorten Erfelijkheid in Odoo
Odoo ondersteunt drie verschillende types modelerfelijkheid, en elk type behandelt velden op een andere manier.
1. Klassieke Erfelijkheid
Dit is het meest voorkomende patroon in Odoo-ontwikkeling. Je gebruikt _inherit zonder een nieuwe _name te definiëren. Dit breidt een bestaand model direct uit door nieuwe velden of methoden toe te voegen. Er wordt geen nieuwe database-tabel aangemaakt. De nieuwe velden verschijnen eenvoudig op het oorspronkelijke model.
Dit is hoe de meeste Odoo-modules velden aan standaardmodellen toevoegen. Als je de CRM-module installeert, voegt deze velden toe aan res.partner via klassieke erfelijkheid. Die velden worden opgeslagen in de partner-tabel naast de kernvelden.
2. Prototype Erfelijkheid
Dit is wanneer je _inherit en _name samen combineert. Het nieuwe model begint als een kopie van de structuur van het oudermodel, maar krijgt zijn eigen database-tabel. Alle oudervelden worden gedupliceerd in het nieuwe model. Wijzigingen in het kindmodel hebben geen invloed op het oudermodel.
Dit patroon is minder gebruikelijk in dagelijkse aanpassingen, maar wordt gebruikt om volledig nieuwe modellen te creëren die de structuur van een bestaand model delen.
3. Delegatie Erfelijkheid
Dit is het meest onderscheidende type, gedefinieerd met _inherits. Het kindmodel koppelt aan een oudermodel via een Many2one-veld. Het kindmodel stelt vervolgens transparant alle velden van de ouder beschikbaar alsof ze van hemzelf zijn. De gegevens bevinden zich in de tabel van de ouder, niet in de tabel van het kind.
Dit is wat de meeste ontwikkelaars bedoelen wanneer ze in strikte zin praten over geërfde velden. De velden worden niet gedupliceerd. Ze worden benaderd via de relationele link tijdens het lezen en schrijven.
Het meest bekende voorbeeld in standaard Odoo is de relatie tussen res.users en res.partner. Elke gebruiker is ook een partner. De naam, e-mail en telefoonnummer van de gebruiker worden opgeslagen op het partnerrecord en benaderd door de gebruiker via delegatie-erfelijkheid.
Hoe het veld werkt
Delegatie-erfelijkheid Onder de Motorkap
Wanneer een model _inherits gebruikt, creëert Odoo's ORM een transparante brug tussen twee database-tabellen. Wanneer je een geërfd veld op het kindrecord leest, volgt Odoo automatisch de Many2one-link naar het ouderrecord en retourneert de waarde die daar is opgeslagen.
Wanneer je naar een geërfd veld van het kindmodel schrijft, schrijft Odoo rechtstreeks naar het ouderrecord. Vanuit het perspectief van de ontwikkelaar voelt het veld als inheems. Vanuit het perspectief van de database leeft de data in de oudertabel.
Dit heeft een belangrijke consequentie: er is geen dataduplicatie. Als je de naam van een partner bijwerkt, wordt die wijziging onmiddellijk overal weerspiegeld waar de partner wordt genoemd, inclusief op het gebruikersrecord dat ervan erft.
Klassieke Erfelijkheid en de Database
Bij klassieke erfelijkheid worden nieuwe velden toegevoegd aan de database-tabel van het oorspronkelijke model. Er is geen tweede tabel betrokken. Het uitgebreide model en het oorspronkelijke model zijn hetzelfde in de database. Dit is de schoonste en meest gebruikelijke manier om velden toe te voegen in Odoo-aanpassingsprojecten.
Gerelateerde Velden als Lichtgewicht Erfelijkheid
Een related veld is een speciaal type berekend veld in de Odoo ORM dat een waarde leest van een gekoppeld record via een keten van relationele velden. Het is niet strikt hetzelfde als modelerfelijkheid, maar het wordt vaak gebruikt om geërfde stijldata op een model weer te geven zonder de structuur van het model te wijzigen.
Bijvoorbeeld, je zou een partner_country_id veld op een verkooporder kunnen definiëren dat partner_id.country_id leest. Het veld gedraagt zich als een inheems veld op de verkooporder, maar de waarde komt van de partner.
Gerelateerde velden kunnen optioneel in de database worden opgeslagen met store=True, wat de zoek- en filterprestaties verbetert, maar opslagoverhead toevoegt en herberekening vereist wanneer de bron verandert.
Hoe velden worden opgelost tijdens runtime
Wanneer Odoo een modeldefinitie laadt, lost het de volledige veldenkaart op, inclusief alle geërfde velden. Tegen de tijd dat een model klaar is voor gebruik, heeft Odoo elke toegankelijke veld al gekoppeld aan zijn bron, of die bron nu de eigen tabel van het model is, een bovenliggende tabel via delegatie, of een gerelateerde keten. Deze resolutie gebeurt eenmaal bij het opstarten van de server en wordt gecached voor prestaties.
Zakelijke gebruikscases
Geërfde velden zijn niet alleen een technisch concept. Ze lossen echte zakelijke problemen op door gegevens consistent te houden over verschillende delen van Odoo zonder duplicatie.
1. CRM en Verkoop: Contactinformatie
Wanneer een verkoper een lead aanmaakt in de CRM-module, komen de klantnaam, telefoonnummer en e-mailadres van het partnerrecord via een Many2one-koppeling. Als de gegevens van de partner veranderen, weerspiegelt elke lead, offerte en bestelling die aan die partner is gekoppeld de update onmiddellijk.
Dit is klassieke erfelijkheid en gerelateerde velden die samen werken. De CRM-module breidt res.partner uit met CRM-specifieke velden (zoals leadaantal en opportuniteitsfase), en verkooporders tonen partnercontactinformatie via gerelateerde velden.
2. Producten en Varianten
Het productmodel van Odoo gebruikt delegatie-erfelijkheid om productvarianten op een nette manier te beheren. Het product.product model (een specifieke variant) gebruikt _inherits om te linken naar product.template. Velden die gedeeld worden over alle varianten, zoals productnaam, categorie, verkoopprijs en beschrijving, bevinden zich op de sjabloon. Variant-specifieke velden zoals barcode of interne referentie bevinden zich op het variantrecord zelf.
Dit ontwerp betekent dat je 50 kleurvarianten van een shirt kunt hebben, die allemaal dezelfde naam en beschrijving delen, zonder die waarden 50 keer in de database op te slaan.
3. Gebruikers en Partners
Elke Odoo-gebruiker is ook een contact. Het res.users model gebruikt _inherits = {'res.partner': 'partner_id'}, wat betekent dat de gebruiker automatisch alle partnervelden erft, inclusief naam, e-mail, telefoon, adres en profielfoto. Wanneer je het e-mailadres van een werknemer bijwerkt, wordt het tegelijkertijd bijgewerkt in zowel de gebruikersinstellingen als het contactenboek.
4. Voorraad: Voorraadbewegingen en Productinformatie
Voorraadbeweginglijnen in de Inventmodulen tonen productbeschrijvingen die afkomstig zijn van de producttemplate via een keten van gerelateerde velden. Magazijnbeheerders zien nauwkeurige, actuele productinformatie rechtstreeks in hun picklijsten zonder dat de inventaris module productgegevens hoeft te dupliceren.
5. Boekhouding: Factuurlijnen
Boekhoudbeweginglijnen verwijzen naar producten en partners. De productnaam, rekeningcodes en belastingconfiguraties die op een factuurlijn worden weergegeven, komen uit de product- en partnermodellen via relationele koppelingen en gerelateerde velden. Boekhouders zien consistente gegevens die overeenkomen met wat verkoopteams op het product hebben geconfigureerd, omdat ze uit dezelfde bron lezen.
Geërfde velden maken of aanpassen
Odoo Studio gebruiken
Odoo Studio is de no-code interface voor het aanpassen van Odoo-modellen en -weergaven. Vanuit Studio kun je nieuwe velden aan elk model toevoegen zonder Python-code te schrijven. Wat Studio onder de motorkap doet, is klassieke overerving: het breidt het model uit door een nieuw veld aan de definitie toe te voegen.
Studio laat je ook gerelateerde velden maken. Wanneer je "Gerelateerd Veld" als veldtype kiest, kun je naar elk veld wijzen dat toegankelijk is via een relationele keten vanuit het huidige model. Bijvoorbeeld, op het verkooporder model kun je een gerelateerd veld maken dat het land of het btw-nummer van de klant rechtstreeks uit het partnerrecord leest.
Voor de meeste zakelijke gebruikers en functionele consultants is Studio het juiste hulpmiddel om velden aan Odoo toe te voegen. Het regelt automatisch de naamgeving van velden, database-migratie en plaatsing in de weergave.
Technische Aanpassing met Python
Voor ontwikkelaars die Odoo-modules bouwen, worden geërfde velden gedefinieerd in Python met de models.Model klasse van de Odoo ORM.
Klassieke overerving om een aangepast veld toe te voegen aan een bestaand model:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Geschatte Contractwaarde'
)Delegatie-overerving om een nieuw model te creëren dat velden deelt van een bestaand model:
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'
)Gerelateerde velden om een waarde uit een gekoppeld record weer te geven:
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Klantland',
store=True
)Via XML-RPC API (Remote Configuratie)
Velden kunnen ook programmatisch worden toegevoegd met behulp van Odoo's XML-RPC API en het ir.model.fields model. Dit is de aanpak die wordt gebruikt in de remote config notebooks van Dasolo. Het is gelijkwaardig aan wat Studio doet, en het stelt je in staat om velden te creëren zonder directe servertoegang.
Om een gerelateerd veld via de API toe te voegen, maak je een ir.model.fields record aan met ttype='many2one' (of het juiste type) en stel je de related parameter in om het relationele pad te definiëren. Deze aanpak is goed geschikt voor het implementeren van aangepaste velden als onderdeel van een geautomatiseerd installatieproces.
Beste praktijken
Kies het juiste type erfelijkheid voor de taak
Gebruik klassieke erfelijkheid wanneer je eenvoudigweg velden of methoden aan een bestaand model wilt toevoegen. Het is de eenvoudigste aanpak en is wat de overgrote meerderheid van Odoo-modules gebruikt. Reserveer delegatie-erfelijkheid voor gevallen waarin je echt twee afzonderlijke recordsets nodig hebt die aan elkaar zijn gekoppeld, zoals wanneer een bedrijfsconcept een contact uitbreidt zonder zelf een contact te zijn.
Geef de voorkeur aan gerelateerde velden voor leesrechten
Als je alleen een waarde uit een gekoppeld record op een formulier of lijstweergave hoeft weer te geven, is een gerelateerd veld schoner dan delegatie-erfelijkheid. Het voorkomt het creëren van een nieuwe structurele afhankelijkheid en is gemakkelijk te begrijpen en te onderhouden.
Wees voorzichtig met store=True op gerelateerde velden
Het opslaan van een gerelateerd veld in de database versnelt zoekopdrachten en filters, maar het betekent dat de waarde een kopie is. Odoo activeert herberekening wanneer de bron verandert, maar in randgevallen kan dit uit sync raken. Sla gerelateerde velden alleen op wanneer je ze echt nodig hebt om op grote schaal te filteren of sorteren.
Prefixeer aangepaste velden altijd met x_
Elk veld dat je aan een standaard Odoo-model toevoegt via overerving, moet beginnen met x_ (of gebruik een module-namespace in een juiste module). Dit voorkomt conflicten met velden die door Odoo in toekomstige versies zijn toegevoegd.
Documenteer je overervingsketen
Wanneer je aan complexe aanpassingen werkt, schrijf dan een korte opmerking of ontwerpaantekening waarin wordt uitgelegd waar velden vandaan komen en waarom. Een veld genaamd x_country_code op een verkooporder linkt misschien niet vanzelfsprekend terug naar partner_id.country_id.code zonder documentatie.
Verwerk cascade-verwijderingen correct
Bij delegatie-overerving wordt het bovenliggende record automatisch aangemaakt wanneer het kind wordt aangemaakt. Wanneer het kind wordt verwijderd, moet het bovenliggende record meestal ook worden verwijderd. Stel ondelete='cascade' in op de Many2one in _inherits om een schone verwijdering zonder weesrecords te garanderen.
Veelvoorkomende valkuilen
Verwarring tussen de drie overervingssoorten
De meest voorkomende fout voor ontwikkelaars die nieuw zijn in Odoo, is het gebruik van _inherit met _name wanneer ze klassieke extensie bedoelden. Dit creëert per ongeluk een gloednieuw model in plaats van het bestaande uit te breiden. Controleer je modeldefinitie: als je niet van plan bent een nieuw model te creëren, laat dan _name weg.
Vergeten het bovenliggende record te creëren in _inherits
Bij delegatie-overerving creëert het bovenliggende record zich niet automatisch in alle scenario's. Wanneer je een kindrecord programmatically via de API of in een script aanmaakt, moet je ofwel Odoo's ORM het bovenliggende record laten aanmaken (wat het doet wanneer je create normaal gebruikt) of het bovenliggende record eerst aanmaken en de ID doorgeven. Het overslaan van deze stap resulteert in een databasebeperkingsfout.
Proberen het type van een veld te wijzigen via overerving
Odoo staat niet toe dat het type van een bestaand veld via overerving wordt overschreven. Je kunt attributen zoals het stringlabel, domein of helptekst wijzigen, maar je kunt een Char-veld niet veranderen in een Integer-veld. Het proberen hiervan zal een fout bij de module-installatie veroorzaken.
Overmatig gebruik van opgeslagen gerelateerde velden
Het is verleidelijk om store=True aan elk gerelateerd veld toe te voegen omwille van prestatieoverwegingen, maar dit vergroot de databasegrootte en introduceert onderhoudskosten. Als het bronveld vaak verandert, veroorzaken opgeslagen gerelateerde velden veel herberekeningen. Gebruik opgeslagen gerelateerde velden selectief, alleen wanneer je een concrete behoefte hebt om ze te filteren of te groeperen in grote datasets.
Aannemen dat geërfde velden de toegangregels van het kindmodel respecteren
Velden die via delegatie zijn geërfd, bevinden zich op het oudermodel. Toegangsrechten die op het kindmodel zijn gedefinieerd, zijn niet automatisch van toepassing op die velden op database-niveau. Als je de toegang tot het kindmodel beperkt maar niet tot het oudermodel, kunnen gebruikers mogelijk nog steeds de waarden van de geërfde velden rechtstreeks via het oudermodel lezen. Beoordeel altijd de beveiligingsregels voor beide modellen bij het gebruik van delegatie-erfenis.
Conclusie
Geërfde velden zijn geen nichefunctie van Odoo-ontwikkeling. Ze zijn ingebakken in de architectuur van het systeem. De relatie tussen gebruikers en partners, tussen productvarianten en sjablonen, tussen verkooporders en klantcontactinformatie: al deze afhankelijkheden vertrouwen op veld-erfenis om gegevens consistent te houden en duplicatie te vermijden.
Begrijpen welk type erfenis je moet gebruiken, wanneer je in plaats daarvan een gerelateerd veld moet gebruiken, en hoe deze mechanismen zich in de database gedragen, zal je een aanzienlijk effectievere Odoo-customizer maken. Je zult schonere code schrijven, betere datamodellen ontwerpen en minder tijd besteden aan het debuggen van onverwacht veldgedrag.
De belangrijkste conclusie is eenvoudig: Odoo's ORM is ontworpen zodat velden op één plek leven en vanuit vele plekken worden benaderd. Dit is het principe achter geërfde velden, en het is wat Odoo's datamodel coherent houdt, zelfs als het groeit over tientallen onderling verbonden modules.
Hulp nodig bij uw Odoo-implementatie?
Bij Dasolo helpen we bedrijven met de implementatie, aanpassing en optimalisatie van Odoo. Of je nu een aangepaste module vanaf nul bouwt, standaardmodellen uitbreidt met nieuwe velden, of probeert te begrijpen waarom je datamodel zich op onverwachte manieren gedraagt, ons team heeft de praktische Odoo-ervaring om je te helpen sneller vooruit te gaan en kostbare fouten te vermijden.
Als je vragen hebt over je Odoo-datamodel, strategie voor aangepaste velden of technische implementatie, praten we graag je situatie door. Neem contact met ons op en laten we de juiste aanpak voor jouw project vinden.