Johdanto
Kun aloitat Odoo‑kehityksen, törmäät pian käsitteeseen "perintä". Odoon ORM on rakennettu niin, että malleja voi laajentaa ja yhdistää toisiinsa — tavoitteena on uudelleenkäytettävyys ilman turhaa tiedon monistamista tai toistuvaa koodia.
Perityt kentät ovat tämän arkkitehtuurin ydintä. Niiden avulla yksi malli voi näyttää ja muokata toisen mallin kenttiä ikään kuin ne kuuluisivat sille itselleen. Kun tämä logiikka aukeaa, Odoon tietomallin monet konstruktiot alkavat asettua paikalleen.
Tässä artikkelissa käyn läpi, mitä perityt kentät ovat, millaisia perintätapoja Odoossa on, miten tiedot tallentuvat tietokantaan ja miten voit hyödyntää näitä mekanismeja käytännön räätälöinneissä.
Mitä tarkoittaa peritty kenttä Odoossa?
Odoossa kenttä on "peritty", kun malli pääsee käsiksi toisen mallin kenttiin jonkin perintätavan kautta sen sijaan, että kenttä määriteltäisiin uudelleen. Lapsimalli hyödyntää olemassa olevaa kenttää sen sijaan, että kopioisi sen rakenteen kokonaan.
Tämä tekee datarakenteista tiiviitä ja yhdenmukaisia. Esimerkiksi asiakkaan nimi tallennetaan yhteen paikkaan ja sama tieto näkyy myyntitilauksilla, CRM‑merkinnöillä ja laskuilla — kaikki lukevat samaa lähdettä.
Odoon perinnän kolme muotoa
Odoo tarjoaa kolme erilaista tapaa laajentaa tai jakaa mallien kenttiä, ja kukin tapa vaikuttaa kenttien tallennukseen eri tavalla.
1. Klassinen perintä
Usein käytetty tapa: ilmoitat _inherit ilman uutta _name-määrittelyä. Tällöin laajennat olemassa olevaa mallia lisäämällä kenttiä tai metodeja suoraan siihen. Uutta taulua tietokantaan ei synny; kentät lisätään olemassaolevaan tauluun.
Tällä tyylillä monet moduulit lisäävät kenttiä Odoon vakio‑malleihin. Esimerkiksi CRM‑moduuli voi lisätä kenttiä res.partner-tauluun klassisen perinnän kautta, jolloin kaikki tiedot ovat samassa rivissä kumppanin muiden kenttien kanssa.
2. Prototyyppiperintä
Tämän yhdistelmän tunnistaa siitä, että käytetään sekä _inherit- että _name-asetuksia. Lapsimalli kopioi vanhemman rakenteen, mutta saa oman tietokantataulunsa. Vanhemman kentät kopioidaan lapsen tauluun, eikä lapsen muutokset vaikuta vanhempaan.
Tätä mallia käytetään harvemmin arkipäivän pienissä muutoksissa, mutta se sopii, kun halutaan uusi malli, joka jakaa vanhemman rakenteen ilman yhteistä tietovarastoa.
3. Delegaatio‑perintä
Erottuva malli syntyy _inherits-asetuksella: lapsimalli linkittää vanhempaan Many2one‑kentällä ja esittää kaikki vanhemman kentät omiltaan. Varsinainen data säilyy vanhemman taulussa, ei lapsen omaan tauluun kopioituna.
Usein "perityillä kentillä" tarkoitetaan nimenomaan tätä delegaatiota: kenttiä ei duplikoida, vaan niiden arvoihin viitataan relaation kautta lukiessa ja kirjoittaessa.
Hyvä esimerkki löytyy Odoon vakio‑malleista: res.users ja res.partner. Käyttäjä on myös kontakti, joten nimi, sähköposti ja puhelin löytyvät partner‑tietueesta ja näkyvät käyttäjän näkymissä delegaation kautta.
Miten kenttä toimii käytännössä
Delegaatio perinpohjin
Kun malli käyttää _inherits-määritystä, ORM muodostaa näkymättömän sillan kahden taulun väliin. Lukiessasi perittyä kenttää lapsitietueelta, Odoo seuraa Many2one‑viitettä vanhempaan ja palauttaa siellä tallennetun arvon.
Kirjoitettaessa arvoa lapsimallin kautta, Odoo tallentaa suoraan vanhempaan tietueeseen. Kehittäjälle kenttä tuntuu omalta, mutta tietokannassa data sijaitsee vanhemman taulussa.
Tämän ansiosta tietoa ei kopioida. Kun kumppanin nimi muuttuu, muutos näkyy välittömästi kaikissa viitteissä — myös käyttäjä‑ tai muissa lapsitehtävissä, jotka lukevat samaa kenttää.
Klassinen perintä ja tietokanta
Klassisessa perinnässä lisätyt kentät ovat osa alkuperäisen mallin tietokantataulua. Ei synny erillistä lapsen taulua. Tämä on usein selkein ja yksinkertaisin tapa laajentaa malleja Odoossa.
Related‑kentät kevyeen perintätunteeseen
Related‑kenttä on laskettu kenttä, joka lukee arvon relaatioiden ketjun läpi yhdestä toiseen tietueeseen. Se ei ole sama asia kuin mallien perintä, mutta sen avulla voi näyttää toisen mallin tietoja ilman, että muokataan nykyisen mallin rakennetta.
Esimerkiksi myyntitilaukselle voit lisätä partner_country_id-kentän, joka lukee arvon partner_id.country_id‑polusta. Tulos näkyy myyntitilauksella kuin oma kenttä, vaikka arvo tulee partnerilta.
Related‑kentät voi myös tallentaa tietokantaan store=True‑asetuksella. Se parantaa hakujen suorituskykyä, mutta kasvattaa tietokantaa ja vaatii uudelleenlaskentaa, kun lähdetieto muuttuu.
Miten kentät ratkaistaan ajonaikaisesti
Kun Odoo lataa mallin määritelmän, se rakentaa kenttäkartan mukaan lukien kaikki perityt kentät. Ennen kuin malli otetaan käyttöön, Odoo on yhdistänyt jokaiseen kenttään sen lähteen — olipa se oma taulu, vanhemman taulu delegaation kautta tai related‑ketju. Tämä resoluutio tehdään kerran palvelimen käynnistyksessä ja välimuistitetaan suorituskyvyn vuoksi.
Liiketoimintatapaukset ja miksi perityt kentät ovat käytännön kannalta tärkeitä
Perityt kentät eivät ole pelkkä tekninen niksi — ne ratkaisevat arjen ongelmia pitämällä tiedot yhdenmukaisina eri Odoo‑alueilla ilman monistamista.
1. CRM ja myynti: yhteystiedot
Myyjä kirjautuessaan liidiin tai tarjoukseen hakee asiakkaan nimen, puhelimen ja sähköpostin partner‑viitteen kautta. Kun partnerin tiedot päivittyvät, sama päivitys näkyy kaikissa liitteissä, tarjouksissa ja tilauksissa, jotka viittaavat kyseiseen partneriin.
Tässä yhdistyvät klassinen laajennus ja related‑kentät: CRM laajentaa res.partner-mallia CRM‑tiedoilla, ja myyntitilaukset tuo kontaktitiedot näkyviin related‑kenttien kautta.
2. Tuotteet ja variantit
Tuotemalli hyödyntää delegaatiota varianttien käsittelyssä: product.product linkkaa product.template-malliin _inherits-rakenteella. Mallin jakamat kentät, kuten nimi, kategoria, hinta ja kuvaus, ovat template‑tasolla, kun taas varianttikohtaiset ominaisuudet jäävät variantille.
Tämän ansiosta esimerkiksi 50 eri väristä paitaa voi jakaa saman nimen ja kuvauksen ilman, että sama teksti tallennetaan 50 kertaa.
3. Käyttäjät ja kontaktit
Jokainen Odoo‑käyttäjä on myös kontakti: res.users perii kontaktin kentät res.partner:sta. Siksi työntekijän sähköpostin muuttaminen käy kerralla sekä käyttäjän asetuksissa että yhteystiedoissa.
4. Varasto: siirrot ja tuotetiedot
Varastotapahtumien riveillä näytettävät tuotetiedot tulevat usein template‑tason kentistä related‑ketjun kautta. Varastovastaavat näkevät aina ajantasaiset tuotekuvaukset ilman, että varastomoduulin tarvitsee kopioida tuotetietoa omiin tauluihinsa.
5. Kirjanpito: laskurivit
Kirjanpidon riveillä näkyvät tuotteen nimi, tilikoodit ja verotiedot haetaan tuotteen ja partnerin malleista relaatiopolkujen kautta. Tiliotteet ja laskut näyttävät samat arvot, joita myynti on tuotteelle määrittänyt, koska kaikki lukee samaa lähdettä.
Kuinka luoda tai muokata perittyjä kenttiä
Odoo Studio ja kenttien lisääminen ilman koodia
Odoo Studio tarjoaa käyttöliittymän kenttien lisäämiseen ilman Pythonia. Studio tekee taustalla klassista perintää: se laajentaa mallia ja lisää uuden kentän sen määritelmään ja tietokantaan.
Studion avulla voi myös luoda related‑kenttiä. Valitsemalla "Related Field" voit osoittaa polun, jolta arvo noudetaan — esimerkiksi myyntitilaukselle asiakkaan maa tai Y‑tunnus suoraan partner‑tietueelta.
Useimmille liiketoimintakäyttäjille ja konsulttiprojekteihin Studio on riittävä: se hoitaa kenttien nimeämisen, tietokantamuutokset ja näkymiin sijoittamisen automaattisesti.
Tekninen räätälöinti Pythonilla
Kehittäjät määrittelevät perityt kentät Odoon ORM‑luokissa Pythonissa perimällä models.Model:stä ja käyttämällä oikeita asetusavainsanoja.
Klassinen perintä esimerkkinä: lisää kenttä olemassaolevaan malliin
Esimerkki Python‑koodista näyttää miten lisäät float‑kentän CRM‑leadille — tämä lisää sarakkeen suoraan lead‑tauluun.
Delegaatio‑perintä esimerkkinä: uusi malli, joka käyttää vanhemman kenttiä
Delegaatio‑mallissa luot uuden taulun ja montaone‑kentän, joka lujittaa linkin partneriin. Vanhemman kentät ovat silti partner‑taulussa ja näkyvät lapselle läpinäkyvästi.
Related‑kenttä esimerkkinä: tiedon tuominen linkitetystä tietueesta
Related‑kenttä voidaan määritellä lukemaan arvo toisesta mallista ja tallentaa sen jos halutaan, esimerkiksi asiakkaan maa myyntitilaukselle.
Etäkonfiguraatio XML‑RPC:llä
Kenttiä voi luoda myös ohjelmallisesti XML‑RPC‑rajapinnan kautta lisäämällä uusia ir.model.fields-tietueita. Tämä on sama lopputulos kuin Studion käyttäminen, mutta soveltuu automatisoituun käyttöönottoon ilman suoraa palvelimen käsiintallennusta.
Related‑kentän luomisessa API:lla määrität kenttätyypin (esim. many2one) ja asetat related-polun. Tämä on toimiva tapa deploy‑prosessiin, jossa haluat generoida kenttiä etänä.
Hyvät käytännöt
Valitse perintätapa tarkoituksen mukaan
Käytä klassista perintää kun haluat yksinkertaisesti lisätä kenttiä tai toimintoja olemassa olevaan malliin — se on suoraviivaisin ja yleisin tapa. Delegaatio kannattaa silloin, kun tarvitset erillisiä tietuejoukkoja, jotka kuitenkin jakavat tiettyjä kenttiä (esimerkiksi kun liiketoimintakäsite laajentaa kontaktia mutta ei ole itse kontakti).
Priorisoi related‑kentät lukutarkoituksiin
Jos tarvitset vain arvon näyttämistä lomakkeella tai listassa, related‑kenttä on usein puhtaampi ratkaisu kuin delegaatio. Se ei tuo mukanaan uutta rakenteellista riippuvuutta ja on selkeä ylläpitää.
Varo store=True‑asetusta related‑kentillä
Tallennettu related‑kenttä nopeuttaa hakuja ja suodatuksia, mutta on kopio tiedosta. Recomputet voivat kuormittaa järjestelmää jos lähdetieto muuttuu usein. Tallenna vasta, kun oikeasti tarvitset suorituskykyetuja suodatus‑ tai ryhmittelyoperaatioissa.
Käytä x_‑etuliitettä omille kentille
Kun lisäät kenttiä vakio‑malleihin, nimeä ne x_-alkuisiksi tai käytä moduulin nimeä kenttätilassa. Näin vältät yhteentörmäykset tulevien Odoo‑päivitysten kanssa.
Dokumentoi perintäketjut
Monimutkaisissa räätälöinneissä jätä kommentti tai suunnittelumuistiinpano siitä, mistä kentät tulevat ja miksi. Ilman dokumentaatiota kentän alkuperä voi hämmentää tulevia ylläpitäjiä.
Huolehdi ondelete‑käsittelystä
Delegaatiossa vanhempatietue luodaan usein automaattisesti lapsen luonnin yhteydessä. Kun lapsi poistetaan, vanhempi kannattaa yleensä poistaa myös. Aseta ondelete='cascade' Many2one‑kenttään, jotta orvona olevia rivejä ei jää tietokantaan.
Yleisimmät sudenkuopat
Kolmen perintätyypin sekoittaminen
Yleisin aloittelijan virhe on käyttää _inherit yhdessä _name:n kanssa silloin, kun haluttiin klassinen laajennus. Lopputuloksena syntyy uusi malli sen sijaan, että vanhaa olisi muokattu. Tarkista aina oletko todella luomassa uutta mallia.
Unohtaa vanhemman luonti _inherits‑tilanteessa
Delegaatiossa vanhempaa ei aina luoda itsestään kaikissa tilanteissa, erityisesti kun luot tietueita API:n kautta. Käytä ORM:n create‑metodia normaalisti tai luo vanhempi ensin ja anna sen ID lapselle — muuten saat tietokanta‑virheen.
Kenttätyypin muuttamisen yrittäminen perinnällä
Odoo ei salli olemassa olevan kenttätyypin vaihtamista perinnän kautta. Voit muuttaa metatietoja kuten labelia tai apua, mutta et voi muuttaa Charista Integeriksi. Tällainen muutos aiheuttaa moduulin asennusvirheen.
Liiallinen store=True‑käyttö
On houkuttelevaa asettaa kaikki related‑kentät tallennetuiksi suorituskyvyn vuoksi, mutta se kasvattaa tietokantaa ja ylläpitotaakkaa. Jos lähdekenttä muuttuu usein, tallennetut related‑kentät aiheuttavat paljon uudelleenlaskentaa. Käytä niitä harkiten.
Olettaa, että perityt kentät noudattavat lapsimallin käyttöoikeuksia
Delegaatioon perustuvat kentät sijaitsevat vanhemmalla mallilla. Lapsimallin käyttöoikeudet eivät automaattisesti rajoita pääsyä näihin kenttiin tietokantatasolla. Jos rajoitat vain lapsimallin oikeuksia, käyttäjä saattaa silti saada luvan lukea arvon suoraan vanhemman kautta. Tarkista siis suojauspolitiikat molemmissa malleissa.
Yhteenveto
Perityt kentät eivät ole vain kehittäjille tarkoitettu lisävaruste — ne ovat osa Odoon ydinsuunnittelua. Käyttäjä‑partner‑yhteydet, tuotetemplate‑varianttisuhteet ja myynti‑kontaktit hyödyntävät kaikki perintää yhdenmukaisuuden säilyttämiseksi.
Kun ymmärrät, mikä perintätapa sopii mihinkin tilanteeseen, milloin kannattaa käyttää related‑kenttää ja miten nämä mekanismit tallentuvat tietokantaan, pystyt tekemään puhtaampia räätälöintejä, suunnittelemaan järkevämpiä tietomalleja ja välttämään turhia bugeja.
Ydinviesti on yksinkertainen: Odoon ORM suunnittelee tietojen asettumisen niin, että tieto elää yhdessä paikassa ja sitä käytetään monesta. Tämä periaate pitää järjestelmän eheänä, kun siihen lisätään uusia moduuleja.
Tarvitsetko apua Odoo‑projektissasi?
Me Dasololla autamme yrityksiä implementoimaan, räätälöimään ja optimoimaan Odoota. Olipa kyse uuden moduulin rakentamisesta, vakio‑mallien laajentamisesta tai vaikeasti selitettävän datamalliongelman selvittämisestä, tiimillämme on käytännön kokemus, joka nopeuttaa työtäsi ja vähentää virhearviointeja.
Jos sinulla on kysymyksiä Odoo‑tietomallista, kenttästrategiasta tai teknisestä toteutuksesta, keskustelemme mielellämme tilanteestasi ja ehdotamme seuraavia askelia. Ota yhteyttä niin mietitään yhdessä paras ratkaisu projektiisi.