Readonly-kenttä Odoossa vaikuttaa yksinkertaiselta ominaisuudelta, mutta sillä on merkittävä vaikutus tietojen eheydelle ja käyttöprosessien hallinnalle.
Olitpa järjestelmän käyttäjä ihmettelemässä miksi jotkut kentät ovat muokattamattomia tai kehittäjä joka haluaa kontrolloida kenttien käyttäytymistä, tässä oppaassa käydään läpi kaikki olennaiset näkökulmat.
Kun ymmärrät readonly-kenttien toimintalogiikan, pystyt rakentamaan luotettavampia työnkulkuja, estämään virheellisiä muutoksia ja tekemään järjestelmästä selkeämmän tiimillesi.
Tämä opas tarkastelee sekä liiketoiminnan että teknisen tason ratkaisuja readonly-kentille — käytännön konfiguroinnista aina kehittäjätyökaluihin asti.
Mikä on readonly-kenttä Odoossa
Readonly-kenttä näyttää tiedon käyttöliittymässä mutta estää sen suoran muokkauksen. Käyttäjä näkee arvon, mutta ei voi kirjoittaa siihen.
Lomakenäkymässä readonly-kentät esitetään yleensä tavallisena tekstinä ilman muokkauskuvakkeita. Näyttö voi olla hieman himmeämpi tai tasaisempi verrattuna muokattaviin kenttiin.
Readonly-ominaisuus voidaan määritellä kahdella eri tasolla Odoossa:
- Mallitasolla (Python/ORM): kenttä on aina readonly kaikissa näkymissä ja konteksteissa
- Näkymätasolla (XML): kenttä on readonly vain tietyssä näkymässä tai tietyin ehdoin
Tämä ero on ratkaiseva: ORM-tasolla readonly estää kirjoitukset kaikista käyttöliittymistä käsin, kun taas näkymätason readonly suojaa kenttää vain siinä tietyssä käyttötilanteessa.
Readonly ei ole oma kenttätyyppinsä vaan attribuutti, jota voi käyttää millä tahansa Odoon kenttätyypillä, kuten Char, Integer, Float, Many2one tai Date. Se on perustyökalu kenttien ajoitus- ja käyttöoikeuslogiikassa.
Miten readonly-kenttä toimii
Kentän käyttäytymisen hahmottamiseksi kannattaa katsoa sekä ORM:n (Python) että näkymätason (XML) puolta.
Readonly ORM-tasolla
ORM-tasolla kentän voi määritellä pysyvästi readonlyksi Python-mallissa. Tämä on tyypillistä lasketuille (computed) kentille, joiden arvo johdetaan muista tiedoista ja joita ei haluta muuttaa käyttöliittymästä.
Tämä readonly-määrittely kuuluu Odoon kenttä-API:in ja se vaikuttaa globaalisti riippumatta siitä, mitä näkymää käytetään.
Tilapohjainen readonly
Yksi yleisimmistä käytännöistä on tehdä kentästä readonly dokumentin tilan perusteella — esimerkiksi lukita tiedot, kun myyntitilaus etenee luonnoksesta vahvistetuksi.
Aiemmissa Odoo-versioissa (16-) tämä tehtiin attrs-ehtolausekkeella XML:ssä. Uudemmissa versioissa syntaksi on tiiviimpi ja readonly-ehdot voi usein ilmaista suoraan kenttäelementissä.
Molemmilla tavoilla saavutetaan sama lopputulos: kenttä on muokattavissa luonnosvaiheessa, mutta lukkiutuu työnkulun edetessä. Tämä on perusajatus kenttien konfiguroinnissa.
Lasketut kentät ja readonly
Lasketut eli computed-kentät ovat oletuksena readonlyja, koska niiden arvot lasketaan automaattisesti muista kentistä.
Jos haluat säilyttää computed-arvon tietokannassa, asetetaan compute ja store=True. Tallennetut computed-kentät helpottavat hakua ja lajittelua ja parantavat suorituskykyä, kun arvoja ei lasketa jatkuvasti uudelleen.
Tehdäksesi lasketun kentän muokattavaksi
Jos haluat sallia manuaalisen syötteen lasketulle kentälle, määrittele sille inverse-metodi. Inverse kertoo Odoolle, miten kirjoitusta käsitellään; ilman sitä kenttä pysyy readonlyna. Tämä on edistyneempää ORM-logiikkaa.
Liiketoimintatapaukset
Readonly-kenttiä käytetään laajasti kaikissa moduuleissa. Seuraavassa viisi käytännön esimerkkiä, joissa readonly suojaa prosessien luotettavuutta.
1. CRM: voitto- tai tappiotilanteen lukitseminen
Myyntiliideissä odotettu liikevaihto ja sulkemispäivä ovat muokattavissa työn alla ollessa, mutta voitto- tai tappiotilanteessa ne lukitaan, jotta historialliset raportit pysyvät oikeina.
Näin estetään tahattomat jälkimuutokset, jotka vääristäisivät myyntianalytiikkaa.
2. Myynti: vahvistettujen tilausrivien suojaaminen
Kun tilaus vahvistetaan, rivit tehdään readonlyksi: tuotteen, määrän tai hinnan muuttaminen ei enää onnistu ilman erillistä korjausprosessia.
Muutos vaatii palautuksen luonnostilaan, mikä jättää selkeän jäljen muutoksen syystä.
3. Varasto: validoitujen siirtojen lukitseminen
Kun toimitus tai vastaanotto on validoitu, tehdyt määrät lukitaan, jotta varaston arvostus ja todelliset siirrot pysyvät synkronissa.
Muokattavat määrät validoinnin jälkeen voisivat rikkoa varastotasoja useissa paikoissa.
4. Kirjanpito: kirjattujen tositteiden rivit
Kirjanpidossa kirjauksen postauksen jälkeen rivit lukitaan. Tämä on usein sekä lakisääteinen vaatimus että olennainen osa tilinpäätöksen luotettavuutta.
Kirjanpidon jälkeiset muutokset heikentäisivät raporttien ja tilinpäätöksen oikeellisuutta.
5. Valmistus: valmistuneen työtehtävän tiedot
Valmistusprosessissa työtehtävän lopputiedot, kuten todellinen kesto ja valmistusmäärät, lukitaan, jotta tuotannon kustannusanalyysit ja suorituskyvyn seuranta perustuvat oikeisiin lukuihin.
Readonly-kentän luominen tai muokkaaminen
Readonly-kentän voi konfiguroida kahdella päämenetelmällä: Odoo Studion kautta ilman koodausta tai suoraan Pythonilla ja XML:llä täyden kontrollin tarpeessa.
Odoo Studio -vaihtoehto
Studio tarjoaa helpon tavan lisätä tai muuttaa readonly-käyttäytymistä ilman koodia. Näin muutat kentän readonlyksi Studion avulla:
- Avaa Odoo Studio päävalikosta (kynä-ikoni)
- Siirry siihen lomakenäkymään, jossa haluat muokata kenttää
- Klikkaa muokattavaa kenttää
- Oikean reunan ominaisuuspaneelissa kytke "Readonly"-asetus päälle
- Tallenna ja sulje Studio
Studio tukee myös ehdollista readonly-käyttäytymistä domain-ilmaisuilla: voit tehdä kentästä readonlyn vain kun jokin tilakenttä on tietyssä arvossa ilman yhtään koodiriviä.
Studio on hyvä valinta konsultille tai ylläpitäjälle, joka haluaa nopeasti ja turvallisesti lisätä sääntöjä. Studio-muutokset tallentuvat tietokantaan eikä niitä yleensä ylikirjoiteta moduulipäivityksissä.
Tekninen muokkaus Pythonilla
Kehittäjät lisäävät readonly-attribuutin suoraan kentän määrittelyyn Python-mallissa. Tämä on perinteinen tapa Odoo-moduulikehityksessä.
Aseta readonly=True pysyvään lukitukseen tai käytä states-parametria, jos haluat että kenttä on muokattavissa vain tietyissä tiloissa.
Tämä pitää logiikan lähellä tietomallia ja on kätevää, kun lisäät omia kenttiä olemassa oleviin malleihin osana räätälöintiä.
Näkymätason XML-attribuutit
Jos haluat readonlyn vain tietyssä näkymässä, lisää readonly-attribuutti kenttäelementtiin view XML:ssä. Tämä on tavallinen tapa toteuttaa käyttöliittymärajoituksia.
Näkymätason etuna on joustavuus: sama kenttä voi olla muokattavissa yhdessä näkymässä ja lukittu toisessa ilman mallin muuttamista.
Odoo 17:ssa inline-ehdot ovat siistimpiä kuin vanhat attrs-rakenteet, mutta molemmat toimivat versiosta riippuen.
Hyvät käytännöt
Readonly-kenttien järkevä käyttö perustuu siihen, että asetat ne oikealle tasolle ja tarkoituksella. Seuraavat suositukset auttavat käytännössä.
1. Käytä näkymätason readonlyta, kun konteksti vaihtelee
Kun kenttä tarvitsee olla lukittu vain tietyissä tiloissa tai näkymissä, tee se näkymässä. Näin backend-prosessit ja API-kirjoitukset voivat tarvittaessa päivittää kenttää.
2. Kohdista readonly dokumentin elinkaareen
Kenttien lukitusten tulisi seurata dokumentin luonnollista työnkulkua: lukitse kentät kun lisämuutokset voisivat aiheuttaa virheitä tai ristiriitoja.
3. Testaa eri käyttäjärooleilla
Readonly voi käyttäytyä eri tavoin riippuen käyttöoikeuksista. Testaa sekä tavallisen käyttäjän että ylläpitäjän rooleilla varmistaaksesi odotetun toiminnan.
4. Yhdistä readonly ja required siellä missä järkevää
Monivaiheisissa lomakkeissa kenttä voi olla pakollinen luonnostilassa mutta readonly myöhemmissä tiloissa. Näin varmistat, että tarvittavat tiedot ovat täytetty ennen etenemistä.
5. Dokumentoi readonly-logiikka
Lisää kommentti tai selitys miksi kenttä on lukittu. Tulevat kehittäjät tarvitsevat liiketoiminnallisen perustelun, ei vain teknistä asetusta.
6. Käytä Studioa nopeisiin ja päivitysturvallisiin muutoksiin
Kun logiikka on yksinkertaista, Studio on hyvä ja turvallinen vaihtoehto. Varaudu Python-räätälöihin silloin, kun tarvitaan monimutkaisempia ehtoja tai integraatioita.
Yleiset sudenkuopat
Vaikka olet kokenut Odoo-käyttäjä, näihin sudenkuoppiin kannattaa varautua etukäteen.
Sekoitus näkymätason readonlyn ja todellisen turvallisuuden välillä
Näkymätason readonly estää vain UI-muokkauksen — se ei estä API-kutsuja, ORM-writeja tai palvelinajoja. Jos haluat estää kaikki kirjoitukset, tee se mallitasolla tai käyttöoikeussäännöillä.
Kenttien tekeminen pysyvästi readonlyksi kun ehdollinen riittäisi
Pysyvä readonly voi estää myös korjaus- tai palautusprosessit. Mieti dokumentin koko elinkaari ennen kuin lukitset kentän lopullisesti.
On muuttujien unohduksen vaikutus onchange-metodeihin
Jos onchange-asetukset yrittävät muuttaa readonly-kenttää, käyttäjä voi nähdä tilapäisiä arvoja tai virheilmoituksia. Varmista, että onchange-logiikka huomioi readonly-tilanteet.
Readonlyn epätasainen soveltaminen eri näkymissä
Muista tarkistaa kaikki näkymät — kenttä voi olla lukittu lomakkeessa mutta muokattavissa listassa tai kanbanissa, jos rajoitusta ei ole lisätty sinne myös.
Perintästandardien sivuvaikutukset
Kun perit standardimallia ja lisäät readonly=True olemassa olevaan kenttään, muutos vaikuttaa kaikkiin näkymiin. Varmista että tämä ei riko muita prosesseja tai moduuleja.
Yhteenveto
Readonly-kentät ovat keskeinen työkalu Odoossa: ne ohjaavat käyttäjiä, suojaavat tietoja ja varmistavat liiketoimintasääntöjen noudattamisen.
Ole tarkka missä tasossa ja millä ehdoilla lukitset kenttiä — paras käytäntö seuraa todellista toimintamallia, ei pelkkää teknistä mukavuutta.
Olipa kyse Studio-konfiguraatiosta tai täysiverisestä Python-/XML-räätälöinnistä, readonly-logiikka on aina sama: näyttää tieto, mutta estää tahattomat muutokset.
Ne eivät ehkä ole Odoo-käyttäytymisen suosituin aihe, mutta oikein käytettynä ne vaikuttavat järjestelmän luotettavuuteen merkittävästi.
Meillä Dasololla autamme yrityksiä ottamaan Odoon haltuun: räätälöinnit, toimintaprosessit ja datamallien optimointi kuuluvat palveluihimme. Ota yhteyttä kerro meille projektistasi.