Johdanto
Jos olet joskus yrittänyt tallentaa lomaketta Odoossa ja huomannut kentän muuttuvan punaiseksi, olet törmännyt pakollisen kentän mekanismiin. Se on yksinkertainen mutta tehokas tapa varmistaa, että tärkeimmät tiedot kerätään järjestelmään ennen kuin tietue tallentuu.
Olitpa rakentamassa myyntiputkea, mallintamassa uusia tietomalleja tai kehittämässä moduulia, pakollisen kentän logiikan tunteminen auttaa estämään puutteellista tietoa ja pitää prosessit luotettavina.
Tässä oppaassa käymme läpi miten pakollinen kenttä käyttäytyy Odoo‑ympäristössä, miten sen voi määrittää Studio‑työkalulla tai Pythonilla, milloin sitä kannattaa käyttää ja mitä virheitä kannattaa välttää.
Mikä on pakollinen kenttä Odoossa
Odoossa attribuutti required on kenttäkohtainen rajoite: tietuetta ei voi tallentaa, ellei kentässä ole arvoa. Se koskee useimpia kenttätyyppejä: tekstikenttiä, numeroita, valintakenttiä, many2one‑viittauksia, päivämääriä jne.
Required on osa Odoon ydintietomallia ja yksi tavallisimmista räätälöinnissä käytetyistä asetuksista. Se toimii ensimmäisenä suojakerroksena puutteellista tai epäjohdonmukaista tietoa vastaan.
Miten se näkyy käyttöliittymässä
Käyttöliittymässä pakolliset kentät erotetaan valinnaisista. Muokkaustilassa niissä on visuaalinen merkki, ja jos tallennat lomakkeen täyttämättä pakollista kenttää, Odoo korostaa sen ja näyttää virheilmoituksen.
Tämä antaa käyttäjälle välittömän palautteen eikä jätä epäselvyyttä siitä, miksi tallennus estyy — käyttäjä tietää täyttää puuttuvan tiedon ennen jatkamista.
Staattinen vs. dynaaminen pakollisuus
Kentän voi tehdä pakolliseksi kahdella tavalla: staattisesti (aina pakollinen) tai dynaamisesti (pakollinen vain tietyissä olosuhteissa, esimerkiksi toisen kentän arvon perusteella).
Molemmat tavat ovat yleisiä: valinta riippuu siitä, millaista liiketoimintalogiikkaa haluat toteuttaa.
Miten kenttä toimii
Kun ymmärrät required‑attribuutin teknisen toteutuksen, osaat käyttää sitä oikein ja korjata ongelmia nopeammin.
Sovellustason valvonta
Moni yllättyy kun oppii, että required on sovellustason tarkistus — sen hoitaa Odoon ORM ennen kuin data menee tietokantaan.
Asetus required=True ei lisää automaattisesti NOT NULL‑rajoitetta PostgreSQL‑sarakkeeseen. Tarkistus tapahtuu Python‑tasolla Odoon ORM:ssä.
Käytännössä tämä tarkoittaa, että suoraan tietokantaan lisätty data voi kiertää tämän suojan. Siksi on suositeltavaa aina käyttää ORM:ää tai Odoo‑APIa, kun kirjoitat Odoon kenttiä.
Mitä tapahtuu, jos rajoite rikotaan
Kun käyttäjä yrittää tallentaa lomakkeen pakollinen kenttä tyhjänä, tapahtuu kaksi asiaa:
- Käyttöliittymä näyttää kentän punaisena ja näyttää validointivirheen
- Tallennusoperaatio estetään, kunnes kenttä täytetään
Jos validointi laukaistaan ohjelmallisesti (esim. XML‑RPC:n kautta), ORM heittää ValidationError‑poikkeuksen ja kertoo, mikä pakollinen kenttä puuttuu.
Dynaaminen pakollisuus domainien avulla
Odoon näkymäkerroksessa required voi olla ehdollinen näkymän ehtojen avulla. Aiemmissa versioissa tämä tehtiin attrs‑attribuutilla näkymä‑XML:ssä:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />Uudemmissa versioissa syntaksi on suorempi: required‑ilmaisu voi olla kenttätagissa:
<field name="x_delivery_date" required="order_type == 'delivery'" />Tämäntyyppiset säännöt elävät näkymissä, eivät mallissa. Mallitason required=True on tiukempi: se pätee aina, kun taas näkymätason ehdot rajoittuvat tiettyihin käyttöliittymätilanteisiin.
ORM‑ ja API‑vuorovaikutus
Kun kutsut create() tai write() ORM:ssä, ORM tarkistaa kaikki required=True‑kentät ennen tietokantaoperaatiota. Jos kenttä puuttuu tai on False, Odoo nostaa ValidationErrorin.
Sama pätee XML‑RPC‑API:iin: jos modelissa määritelty field on required, sen arvo pitää sisällyttää create‑kutsun data‑sanakirjaan tai kutsu epäonnistuu.
Liiketoimintatapaukset
Pakolliset kentät näkyvät läpi Odoon standarditoimintojen ja niiden merkitys korostuu myös räätälöinneissä. Seuraavassa viisi käytännön esimerkkiä, joissa pakollisuus parantaa prosessien luotettavuutta.
1. CRM: Asiakassegmentti pakolliseksi liideille
Myyntitiimi haluaa, että jokainen liidi luokitellaan segmenttiin ennen putkeen siirtämistä. Ilman pakollista kenttää luokittelu jää helposti tekemättä, mikä heikentää raportointia ja kohdentamista.
Merkitsemällä asiakassegmentti‑valinta pakolliseksi CRM‑lomakkeella varmistat, että tieto tallentuu heti, eikä myöhemmin tarvitse arvailla tai korjata puuttuvaa tietoa.
2. Myynti: Toimitusosoite pakolliseksi tilauksilla
Yrityksille, jotka lähettävät fyysisiä tuotteita, toimitusosoite on keskeinen tieto. Jos se ei ole pakollinen, tilaus voidaan vahvistaa puutteellisilla tiedoilla.
Tekemällä toimitusosoitteesta pakollisen myyntitilauksen lomakkeella estät tilauksen vahvistamisen ennen kuin logistiikka saa tarvitsemansa tiedot — näin vältetään täytäntöönpanon virheitä.
3. Varasto: Erä‑ tai sarjanumero pakolliseksi vastaanotolla
Säädellyillä aloilla (elintarvike, lääke, elektroniikka) eränumeron kirjaus vastaanotossa voi olla pakollista. Odoo tukee jäljitettävyyttä tuotteiden seuranta‑asetuksilla, jotka varmistavat erän tai sarjanumeron vaatimuksen varastosiirroissa.
Myös räätälöidyissä vastaanottolomakkeissa laatuviite tai muu pakollinen kenttä takaa, ettei varastoalan henkilökunta unohda tärkeää tietoa.
4. Kirjanpito: Kustannopaikka pakolliseksi ostolaskuissa
Talouden tiimi haluaa usein, että jokainen meno kohdistetaan kustannuspaikalle budjetoinnin takia. Jos kenttä jää tyhjäksi, raportointi kärsii.
Lisäämällä many2one‑kentän kustannuspaikkaan pakolliseksi ostolaskun lomakkeelle varmistat, ettei laskua voi kirjata ilman tätä tietoa — pieni muutos, iso vaikutus datan täydellisyyteen.
5. HR: Työsopimuksen tyyppi pakolliseksi ennen perehdytystä
Henkilöstöhallinnossa halutaan usein, että työsopimuksen tyyppi on tiedossa ennen kuin työntekijän kortti lopullisesti tallennetaan. Pakollinen kenttä estää HR‑tiimiä unohtamasta tätä vaihetta kiireessä.
Kentän luominen tai muokkaus
Kentän voi merkitä pakolliseksi joko Odoo Studiolla ilman koodausta tai Pythonilla moduulissa — valinta riippuu tarpeesta ja kontrollin tasosta.
Odoo Studio ‑työkalun käyttö
Studio on Odoon sisäänrakennettu no‑code‑työkalu, jolla kenttiä voi muokata helposti. Kun avaat Studio‑tilan ja valitset kentän, kenttäasetuksissa näkyy "Pakollinen"‑kytkin.
Tämän kytkimen aktivoiminen merkitsee kentän pakolliseksi näkymässä ja tallentaa asetuksen malliin. Se on nopea ratkaisu yksinkertaisiin tapauksiiin eikä vaadi kehittäjää.
Studio‑rajoitus on se, että se tyypillisesti lisää staattisen pakollisuuden näkymään. Jos haluat ehdollista pakollisuutta muiden kenttien arvojen perusteella, tarvitset näkymä‑XML:ää tai teknistä lähestymistapaa.
Tekninen tapa: Python‑kentät
Räätälöidyssä moduulissa kentän voi tehdä pakolliseksi lisäämällä required=True kentän määrittelyyn. Tämä on standardikäytäntö Odoo‑kehityksessä.
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)Kun pakollisuus asetetaan mallitasolla, vaatimus pätee aina riippumatta siitä, mitä näkymää käytetään tietueen luomiseen — sitä ei voi kiertää eri käyttöliittymässä.
Dynaaminen pakollisuus näkymä‑XML:ssä
Kun pakollisuus tulisi aktivoida vain tietyissä olosuhteissa, lisää vaatimus näkymään, ei malliin. Odoon vanhemmissa versioissa tämä tehtiin attrs‑attribuutilla:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />Uudemmissa versioissa vastaava syntaksi voi olla suorempi:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Tämä on näkymätason rajoite: se pätee vain kun tietuetta käsitellään kyseisen näkymän kautta, joten se on löyhempi kuin mallitason required.
Pakollisten kenttien luominen API:n kautta
Voit luoda kentän ja asettaa sen pakolliseksi myös ohjelmallisesti käyttämällä ir.model.fields‑mallia XML‑RPC‑kutsussa. Tämä on hyödyllistä automatisoiduissa julkaisuprosesseissa.
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Tällöin kenttä luodaan ja sen pakollisuus otetaan käyttöön yhdellä operaatioilla — kätevää, kun haluat automatisoida kenttien luomisen useissa ympäristöissä.
Parhaat käytännöt
Kentän merkitseminen pakolliseksi on yksinkertaista, mutta sen järkevä käyttö vaatii harkintaa. Seuraavat periaatteet auttavat välttämään turhaa kitkaa käyttäjille ja pitämään datan laadukkaana.
1. Tee kentästä pakollinen vain, jos se todella on
Liian monien kenttien pakolliseksi tekeminen on yleinen virhe. Jos käyttäjä ei voi täydentää lomaketta koska tieto ei ole saatavilla, hän saattaa käyttää väliaikaisia arvoja, jotka pilaavat datan laadun.
Ennen kuin teet kentästä pakollisen, mieti: onko tieto aina saatavilla lomakkeen täyttöhetkellä? Jos ei, harkitse pakollisuutta myöhemmässä vaiheessa tai tee se dynaamisesti.
2. Käytä vaihekohtaista validointia aina kun mahdollista
Monivaiheisissa prosesseissa (esim. CRM‑opportunityt tai valmistusorderit) on usein parempi tarkistaa kentät tiettyjen vaiheiden yhteydessä kuin heti luomisvaiheessa. Tätä voidaan toteuttaa Python‑validoinneilla tai automatisoinneilla, jotka aktivoituvat siirryttäessä seuraavaan vaiheeseen.
Tämä lähestymistapa on joustavampi ja helpottaa käyttäjien arkea verrattuna kaikkein kenttien pakolliseksi tekemiseen alusta alkaen.
3. Yhdistä pakolliset kentät järkeviin oletusarvoihin
Jos kenttä on useimmiten ennakoitavissa, aseta sille default‑arvo. Näin käyttäjä säästyy turhalta kirjoittamiselta, mutta kenttä ei silti koskaan jää tyhjäksi.
4. Suosi mallitason pakollisuutta kriittisessä datassa
Jos tieto on liiketoiminnallisesti tai sääntelyvaatimusten kannalta kriittinen, aseta required mallitasolla Pythonissa. Näkymätason vaatimukset voidaan kiertää API‑kutsuilla tai erilaisilla näkymillä.
5. Kommunikoi muutokset käyttäjille
Kun lisäät uusia pakollisia kenttiä olemassa oleviin lomakkeisiin, viestitä muutos etukäteen. Muutoin työn alla olevat tietueet saattavat epäonnistua seuraavan muokkauksen yhteydessä.
6. Testaa tyhjillä ja osittaisilla tiedoilla
Ennen käyttöönottoa testaa uutta konfiguraatiota kokonaisuudessaan: web‑käyttöliittymä, API‑luonti ja kaikki integraatiot tai automaatioskriptit. Tämä on olennainen osa vastuullista käyttöönottoa.
Yleiset sudenkuopat
Kokeneetkin Odoo‑implementoijat törmäävät ajoittain pakollisten kenttien ongelmiin. Tuntemalla tavallisimmat sudenkuopat säästät aikaa ja vältät kalliin peruutuksen.
Sudenkuoppa 1: Pakollinen kenttä mallissa, jossa on jo olemassa tietueita
Kun lisäät required=True kenttään mallissa, joka sisältää jo tuhansia tietueita, ja kentät ovat tyhjiä, käyttäjät saattavat menettää mahdollisuuden tallentaa olemassa olevia tietueita ennen migraatiota.
Ennen rajoitteen käyttöönottoa tarkista olemassa oleva data ja täydennä puuttuvat arvot tarvittaessa tietomigraatiolla.
Sudenkuoppa 2: Näkymätason ja mallitason pakollisuuden sekoittaminen
Pakolliseksi tekeminen vain näkymässä (Studio tai näkymä‑XML) ei takaa vaatimusta muualla. API‑luonti, eri näkymät tai tiedostotuonnit voivat kiertää näkymätason rajoitteen.
Jos tarvitset ehdottoman rajoitteen, käytä required=True kentän Python‑määrittelyssä — tämä on usein ymmärretty väärin ja aiheuttaa tuotantodatan laatuongelmia.
Sudenkuoppa 3: Pakolliset kentät automatisoiduissa toiminnoissa
Kun automaattinen toiminto tai ajastettu jobi luo tietueita, sen pitää toimittaa arvot kaikille pakollisille kentille. Jos automaatio on kirjoitettu ennen pakollisuuden lisäämistä, se alkaa epäonnistua virheilmoituksin.
Käy aina läpi automaatiot ja skriptit, kun lisäät pakollisen kentän olemassa olevaan modeliin.
Sudenkuoppa 4: Tietojen tuonti ilman pakollisia kenttiä
CSV‑tuonnissa tai Odoon tuontityökalulla puuttuvat pakolliset kentät aiheuttavat tuonnin epäonnistumisen. Tämä käyttäytyminen on oikea, mutta yllättää usein ne, jotka odottavat osittaista tuontia.
Sisällytä kaikki pakolliset kentät tuontipohjiin ja dokumentoi mitkä kentät ovat pakollisia tuontiohjeissa.
Sudenkuoppa 5: Pakollista käyttäen monimutkaisen validoinnin sijaan
Required tarkistaa vain, ettei kenttä ole tyhjä — se ei tarkasta arvojen oikeellisuutta tai kenttien välistä loogista yhteyttä. Monimutkaiset säännöt (esim. päivämäärän pitää olla tulevaisuudessa tai kahden kentän välillä pitää olla yhteensopivuus) kannattaa toteuttaa @api.constrains‑tarkistuksella Pythonissa.
Pakollisuuteen tukeutuminen liian laajasti johtaa kankeisiin ja vaikeasti ylläpidettäviin ratkaisuun.
Yhteenveto
Pakollinen kenttä on yksinkertainen mutta tehokas työkalu Odoossa: oikein käytettynä se nostaa datan laatua ja varmistaa kriittisten tietojen kirjaamisen oikeaan aikaan. Väärin käytettynä se hankaloittaa käyttäjän työtä ja synnyttää huonoja kiertoratkaisuja.
Keskeistä on erottaa mallitason ja näkymätason vaatimukset, miettiä tarkasti mitä kenttiä kannattaa vaatia pakollisiksi ja ennakoida, miten muutos vaikuttaa integraatioihin ja automaatioihin.
Oli kyseessä kehittäjän opas, laajempi räätälöintiprojekti tai Studio‑muutos, required‑attribuutin ymmärtäminen erottaa siistin käyttöönoton tilanteesta, joka aiheuttaa ongelmia kuukausia myöhemmin.
Tarvitsetko apua Odoo‑käyttöönotossa?
Me Dasololla autamme yrityksiä ottamaan Odoon käyttöön, räätälöimään moduuleja ja optimoimaan toimintaprosesseja eri toiminnoissa ja vaikeusasteissa. Tarjoamme sekä teknistä että toiminnallista osaamista jokaisessa projektissa.
Jos sinulla on kysymyksiä pakollisista kentistä tai mistä tahansa Odoo‑asetuksestasi, autamme mielellämme. Ota meihin yhteyttä ja keskustellaan, mitä olet rakentamassa.