Johdanto
Jos olet koskaan tallentanut lomakkeen Odoossa ja nähnyt kentän muuttuvan punaiseksi, olet jo kohdannut pakollisen kentän mekanismin. Se on yksi Odoo-tietomallin perusominaisuuksista ja yksi yksinkertaisimmista tavoista varmistaa tietojen laatua liiketoimintaprosesseissasi.
Olitpa sitten määrittämässä Odoota myyntitiimille, luomassa mukautettua mallia tai työskentelemässä teknisessä Odoo-kehitysprojektissa, ymmärtäminen siitä, kuinka required -attribuutti toimii, auttaa sinua rakentamaan luotettavampia prosesseja.
Tämä opas kattaa kaiken: kuinka kenttä käyttäytyy Odoo-kehyksessä, kuinka se määritetään Odoo Studiolla tai Python-koodilla, milloin sitä käytetään ja mitä virheitä kannattaa välttää.
Mikä on pakollinen kenttä Odoossa
Odoossa required-attribuutti on kenttätason rajoite, joka estää tietueen tallentamisen, ellei kenttä sisällä arvoa. Se koskee käytännössä kaikkia Odoo-kenttätyyppejä: tekstikenttiä, numeerisia kenttiä, valintakenttiä, many2one-kenttiä, päivämääriä ja muita.
Se on osa Odoon ydintietomallia ja yksi yleisimmin käytetyistä attribuuteista Odoo-kustomoinnissa. Kentän asettaminen pakolliseksi on ensimmäinen puolustuskeino puutteellisten tai epäjohdonmukaisten tietojen estämiseksi tietokannassasi.
Kuinka se näkyy käyttöliittymässä
Odoo-käyttöliittymässä pakolliset kentät erottuvat visuaalisesti valinnaisista. Kun lomake on muokkaustilassa, pakolliset kentät näyttävät tyypillisesti hienovaraisen visuaalisen indikaattorin. Kun käyttäjä yrittää tallentaa tietuetta täyttämättä pakollista kenttää, Odoo korostaa kenttää punaisella ja näyttää varoitusviestin.
Tämä käyttäytyminen on johdonmukaista verkkoliittymässä. Käyttäjät saavat välitöntä, selkeää palautetta, mikä vähentää mahdollisuutta lähettää puutteellisia tietueita.
Staattinen vs. Dynaaminen pakollisuus
On kaksi tapaa tehdä kentästä pakollinen Odoossa. Ensimmäinen on staattinen pakollisuus: kenttä on aina pakollinen, riippumatta olosuhteista. Toinen on dynaaminen pakollisuus: kenttä tulee pakolliseksi vain, kun tietyt ehdot täyttyvät, perustuen muiden kenttien arvoihin samassa tietueessa.
Molempia lähestymistapoja käytetään säännöllisesti Odoo-kehityksessä. Valinta riippuu liiketoimintalogiikastasi.
Kuinka kenttä toimii
Ymmärtäminen siitä, miten required-attribuutti toimii teknisellä tasolla, auttaa sinua soveltamaan sitä oikein ja vianetsimään ongelmia, kun niitä ilmenee.
Sovellustason valvonta
Tärkeä yksityiskohta, joka yllättää monet Odoo-käyttäjät: required-attribuuttia valvotaan sovellustasolla, ei tietokantatasolla. Tämä tarkoittaa, että rajoite tarkistetaan Odoo ORM:ssä, kun tietue luodaan tai kirjoitetaan, ennen kuin tiedot saavuttavat tietokannan.
Kun asetat required=True kentälle, taustalla olevalle PostgreSQL-sarakkeelle ei oletuksena lisätä NOT NULL -rajoitetta. Validointi tapahtuu Pythonissa, Odoo ORM -kerroksessa.
Käytännössä tämä tarkoittaa, että tietoja, jotka on lisätty suoraan tietokantaan (ohittaen Odoon), ei havaita vaaditun rajoitteen toimesta. Ole aina vuorovaikutuksessa Odoo-tietokannan kenttien kanssa ORM:n tai API:n kautta, jotta voit hyödyntää tätä suojaa.
Mitä tapahtuu, kun rajoite rikotaan
Kun käyttäjä yrittää tallentaa lomakkeen, jossa vaadittu kenttä on jätetty tyhjäksi, tapahtuu kaksi asiaa:
- Kenttä muuttuu punaiseksi käyttöliittymässä, ja Odoo näyttää vahvistusviestin
- Tallennustoiminto estetään, kunnes kenttä on täytetty
Jos laukaise vahvistus ohjelmallisesti (esimerkiksi XML-RPC API:n tai palvelintoiminnan kautta), Odoo nostaa ValidationError -virheen, jossa ilmoitetaan, mikä vaadittu kenttä puuttuu.
Dynaaminen vaatimus käyttämällä domaineja
Odoo-kehyksessä required -attribuutista voidaan tehdä ehdollinen käyttämällä näkötason lausekkeita. Odoo 16:ssä ja aikaisemmin tämä tehdään attrs -attribuutin avulla näkön XML:ssä:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />Odoo 17:ssä ja myöhemmin syntaksi on yksinkertaistettu suoran required -lausekkeen avulla kenttätagissa näkössä:
<field name="x_delivery_date" required="order_type == 'delivery'" />Nämä ehdolliset säännöt sijaitsevat näkötasolla, eivät mallitasolla. Tämä on tärkeä ero: mallitasolla required=True aina pakottaa rajoitteen, kun taas näkötason lausekkeet pätevät vain tietyissä käyttöliittymäkonteksteissa.
Vuorovaikutus ORM:n ja API:n kanssa
Odoo ORM:ssa, kun kutsut create() tai write() -mallia, ORM tarkistaa kaikki kentät, joissa on required=True, ennen kuin se suorittaa tietokantaoperaation. Jos pakollinen kenttä puuttuu tai se on asetettu False:ksi, Odoo nostaa ValidationError:n.
Tämä pätee myös, kun luodaan tietueita XML-RPC API:n kautta. Kaikkien mallin määrittelyssä pakollisiksi merkittyjen kenttien on oltava mukana create-menetelmälle annettavassa tietodiktiossa, muuten kutsu epäonnistuu virheellä.
Liiketoimintakäyttötapaukset
Pakolliset kentät esiintyvät koko Odoo:ssa, ja ne ovat yhtä hyödyllisiä myös mukautetuissa kokoonpanoissa. Tässä on viisi konkreettista esimerkkiä todellisista liiketoimintatyönkuluista, joissa kentän tekeminen pakolliseksi tekee todellisen eron.
1. CRM: Asiakassegmentti pakollinen liideissä
Myyntitiimi haluaa varmistaa, että jokainen liidi on liitetty asiakassegmenttiin ennen kuin se siirretään putkeen. Ilman pakollista kenttää myyntiedustajat usein ohittavat tämän vaiheen, mikä tekee mahdottomaksi raportoida liidien lähteistä segmentin mukaan myöhemmin.
Merkitsemällä mukautetun "Asiakassegmentti" -valintakentän pakolliseksi CRM-liidimuodossa tiimi varmistaa, että tiedot tallennetaan aina syöttöhetkellä. Ei segmenttiä, ei tallennusta.
2. Myynti: Toimitusosoite pakollinen tilauksissa
Fyysisiä tuotteita lähettävien yritysten kohdalla toimitusosoite on kriittinen. Joissakin Odoo-kokoonpanoissa toimitusosoitekenttä ei ole oletusarvoisesti pakollinen, mikä tarkoittaa, että tilauksia voidaan vahvistaa ilman sitä.
Merkitsemällä toimitusosoitekenttä pakolliseksi myyntitilauslomakkeessa estetään tilausta vahvistamasta ennen kuin logistiikkatiimillä on tarvittavat tiedot. Tämä eliminoi yleisen virheiden lähteen täyttöprosessissa.
3. Varasto: Erä- tai sarjanumero pakollinen vastaanotossa
Säännellyillä aloilla (ruoka, lääkkeet, elektroniikka) toimiville yrityksille eränumeroiden seuraaminen vastaanotetuissa tuotteissa ei ole valinnaista. Odoo tukee tätä natiivisti tuotteiden seuranta-asetuksen kautta, joka tehokkaasti pakottaa erä- tai sarjanumeron käytön varastosiirroissa.
Kustomikenttien merkitsemiseksi vastaanottolomakkeilla, kuten laadunvalvontaviitteellä, kentän tekeminen pakolliseksi varmistaa, että varastotiimi ei unohda kirjata tietoja vastaanottoprosessin aikana.
4. Kirjanpito: Kustannuskeskus Pakollinen Toimittajalaskuissa
Rahoitustiimien on usein tarpeen liittää jokainen kulu kustannuskeskukseen budjetin seurannan vuoksi. Ilman valvontaa kirjanpitäjät tai hankintapäälliköt saattavat jättää kentän tyhjäksi, mikä luo aukkoja taloudellisessa raportoinnissa.
Pakollinen many2one-kenttä, joka osoittaa kustannuskeskusmalliin ja on lisätty toimittajalaskulomakkeeseen, varmistaa, että laskua ei voida julkaista ilman tätä määritystä. Tällainen Odoo-mukautus on nopea toteuttaa ja sillä on suora vaikutus tietojen täydellisyyteen.
5. HR: Sopimustyyppi Pakollinen Ennen Työntekijän Aloittamista
HR-tiimit, jotka hallinnoivat työntekijöiden aloittamista Odoossa, haluavat usein varmistaa, että sopimustyyppi kirjataan ennen työntekijätietojen viimeistelyä. Pakollinen kenttä työntekijälomakkeessa estää HR-tiimiä tallentamasta vahingossa puutteellisia työntekijätietoja kiireisen aloittamisjakson aikana.
Kentän luominen tai mukauttaminen
Odoossa on kaksi pääasiallista tapaa merkitä kenttä pakolliseksi: käyttämällä Odoo Studioa koodittomaan lähestymistapaan tai kirjoittamalla Python-koodia täydelliseen hallintaan. Molemmat ovat voimassa riippuen kontekstistasi.
Käyttäen Odoo Studioa
Odoo Studio on sisäänrakennettu kooditon työkalu, joka antaa sinun konfiguroida kenttiä ilman kehitystä. Kun avaat Studion ja valitset kentän lomakkeelta, näet "Pakollinen" kytkimen kenttäominaisuuksien paneelissa oikealla.
Tämän kytkimen aktivointi merkitsee kentän pakolliseksi näkymässä ja tallentaa rajoituksen mallitasolle. Tämä on nopein lähestymistapa yksinkertaisille tapauksille eikä vaadi teknistä tietämystä. Se toimii hyvin sekä standardeille Odoo-kentille että Odoo Studio -kenttien kautta lisätyille mukautetuille kentille.
Studion rajoitus on, että se konfiguroi vain staattisen pakollisen rajoituksen. Dynaamisen pakollisen käyttäytymisen saavuttamiseksi, joka perustuu muihin kenttäarvoihin, sinun on muokattava näkymä XML-suoraan tai käytettävä teknistä lähestymistapaa.
Tekninen Lähestymistapa: Python Kentät
Odoo-moduulissa vaaditun kentän määrittäminen on yhtä yksinkertaista kuin required=True lisääminen kentän määrittelyyn. Tämä on standardimalli Odoo Python -kenttien kehittämisessä:
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='Asiakassegmentti',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Kustannuspaikka',
required=True,
)Tällä lähestymistavalla rajoite toteutuu mallitasolla, mikä tarkoittaa, että se pätee riippumatta siitä, mikä näkymä tai käyttöliittymä käytetään tietueen luomiseen. Sitä ei voida kiertää pääsemällä tietueeseen eri näkymän kautta.
Dynaaminen vaatiminen näkymän XML:ssä
Kun vaatimusta tulisi soveltaa vain tietyissä olosuhteissa, lisää se näkymätasolla sen sijaan, että se olisi mallitasolla. Odoo 16:ssa:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />Odoo 17:ssa:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Tämä on vain näkymään liittyvä rajoite. Se on vähemmän tiukka kuin mallitasolla vaadittu, koska se pätee vain, kun tietuetta muokataan kyseisessä näkymässä, jossa tämä määritelmä on.
Vaadittujen kenttien luominen API:n kautta
Jos käytät XML-RPC API:a kenttien luomiseen (kuten muissa Odoo Data & API -kokoelman artikkeleissa käsitellään), voit asettaa required kutsuessasi create ir.model.fields:ssa. Tämä on osa Odoo-kehittäjän standardiohjetta ohjelmalliseen mukauttamiseen:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Asiakassegmentti',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Tämä luo kentän ja pakottaa vaaditun rajoitteen yhdellä askeleella, mikä on hyödyllistä automatisoiduissa käyttöönotto-työnkuluissa kenttien luomiseen Odoo-skenaarioissa.
Parhaat käytännöt
Kentän merkitseminen vaadituksi vaikuttaa suoraviivaiselta, mutta sen hyvä käyttö vaatii hieman ajattelua. Tässä ovat käytännöt, jotka säästävät aikaasi ja estävät käyttäjiesi turhautumista.
1. Tee Kentistä Vaatimuksena Vain Kun Ne Todella Ovat
Liiallinen kenttien vaatiminen on yksi yleisimmistä Odoo-konfiguraatiovirheistä. Jos käyttäjä ei voi täyttää lomaketta, koska kenttä on vaadittu mutta tieto ei ole vielä saatavilla, he löytävät kiertoteitä (kuten syöttämällä paikkamerkkitietoja), jotka vääristävät tietojasi.
Ennen kuin merkitset kentän vaadituksi, kysy: onko tämä tieto aina saatavilla syöttöhetkellä? Jos vastaus ei ole selkeä kyllä, harkitse sen tekemistä vaatimukseksi myöhemmässä vaiheessa (esimerkiksi vahvistuksessa sen sijaan, että luomisessa) tai käytä dynaamista vaatimusta sen sijaan.
2. Käytä Vaiheittaisia Vaatimuksia Sen sijaan, että Olisi Aina Vaatimuksena
Työnkuluissa, joissa on useita vaiheita, kuten CRM-mahdollisuus tai valmistusmääräys, on usein parempi pakottaa vaaditut kentät tietyissä vaiheissa sen sijaan, että vaatimukset olisivat voimassa alusta alkaen. Tämä tehdään tyypillisesti Python-rajoitusten tai automatisoitujen toimintojen avulla, jotka tarkistavat kenttäarvot, kun tietue siirtyy tiettyyn vaiheeseen.
Tämä malli on joustavampi ja käyttäjäystävällisempi kuin jokaisen kentän tekeminen vaatimukseksi alusta alkaen.
3. Yhdistä Vaaditut Kentät Oikeiden Oletusarvojen Kanssa, Missä Se On Järkevää
Jos kenttä on vaadittu ja sillä on järkevä oletusarvo useimmissa tapauksissa, aseta default kenttä määrittelyyn. Tämä vähentää kitkaa käyttäjille, jotka eivät tarvitse muuttaa oletusarvoa, samalla varmistaen, että kenttä ei koskaan ole tyhjillään.
4. Suosi Mallitason Vaatimuksia Kriittisille Tiedoille
Kriittisille tiedoille (kuten kirjanpitotiedot, sääntelytunnisteet tai pakolliset tunnisteet) pakota rajoitus mallitasolla Pythonissa sen sijaan, että se olisi vain näkymätasolla. Näkymätason vaatimukset voidaan kiertää, jos tietue luodaan API:n kautta tai eri näkymässä, joka ei sisällä rajoitusta.
5. Viestitä vaadittavat kentät loppukäyttäjille
Kun lisäät uusia vaadittuja kenttiä olemassa oleviin lomakkeisiin, työnkulussa olevat käyttäjät saattavat yllättyä. Viesti muutoksista tiimillesi ennen käyttöönottoa, erityisesti jos olemassa olevat tiedot saattavat epäonnistua validoinnissa seuraavassa muokkauksessa.
6. Testaa tyhjillä ja osittaisilla tiedoilla
Ennen kuin otat käyttöön konfiguraation, jossa on uusia vaadittuja kenttiä, testaa aina koko työnkulku tyhjillä arvoilla ja osittaisilla tiedoilla. Tämä sisältää testauksen verkkoliittymän, API:n ja kaikkien automatisoitujen toimintojen tai integraatioiden kautta, jotka luovat tietueita Odoossa. Tämä on perusaskel missä tahansa vastuullisessa Odoo-teknisessä oppaassa.
Yleiset sudenkuopat
Jopa kokeneet Odoo-implementoijat kohtaavat ongelmia vaadittujen kenttien kanssa. Tietäminen, mitä tarkkailla, säästää virheenkorjausaikaa ja estää tuskalliset palautukset.
Vaaranpaikka 1: Kentän tekeminen vaadituksi mallissa, jossa on jo tietueita
Jos lisäät required=True kenttään mallissa, jossa on jo tuhansia tietueita, ja näillä tietueilla ei ole arvoa tälle kentälle, saatat kohdata ongelmia, kun näitä tietueita muokataan seuraavan kerran. Käyttäjät eivät voi tallentaa muutoksia ennen kuin he täyttävät uuden vaaditun kentän.
Ennen kuin otat käyttöön vaatimuksen olemassa olevalle kentälle, tarkista aina, onko olemassa olevilla tietueilla jo arvoja. Jos ei, suorita tietomigraatio kentän täyttämiseksi ensin.
Vaaranpaikka 2: Näkymätason ja mallitasoisen vaatimuksen sekoittaminen
Kentän asettaminen vaadituksi näkymässä (oli se sitten Studio- tai näkymä-XML) ei valvo vaatimusta mallitasolla. API:n, eri näkymän tai tuonnin kautta luotu tietue ohittaa täysin näkymätason vaatimukset.
Jos tarvitset tiukan vaatimuksen, aseta required=True Python-kenttämääritykseen. Tämä on usein väärin ymmärretty kohta Odoo-kenttäoppaassa, ja se aiheuttaa todellisia tietolaatuongelmia tuotannossa.
Vaaranpaikka 3: Vaaditut kentät automatisoiduissa tai aikataulutetuissa toiminnoissa
Kun automatisoitu toiminto tai aikataulutettu toiminto luo tietueita ohjelmallisesti, sen on annettava arvot kaikille pakollisille kentille. Jos toiminto on kirjoitettu ennen kuin pakollinen kenttä lisättiin, se alkaa epäonnistua hiljaa tai kryptisellä virheellä sen jälkeen, kun pakollinen rajoite on otettu käyttöön.
Tarkista aina kaikki automatisoidun tietueen luontikoodi sen jälkeen, kun olet lisännyt pakollisen kentän olemassa olevaan malliin.
Vaaranpaikka 4: Tietojen tuominen, joista puuttuu pakollisia kenttiä
Kun tuodaan tietueita CSV-tiedoston tai Odoo-tuontityökalun kautta, tuontitiedostosta puuttuvat pakolliset kentät aiheuttavat tuonnin epäonnistumisen. Tämä on itse asiassa oikea käyttäytyminen, mutta se yllättää käyttäjät, jotka ovat tottuneet tuomaan osittaisia tietoja.
Sisällytä aina kaikki pakolliset kentät tuontimalleihisi. On hyvä käytäntö dokumentoida, mitkä kentät ovat pakollisia tietojen tuontiohjeissasi.
Vaaranpaikka 5: Pakollisen käytön sijaan Python-rajoitteen käyttö monimutkaiselle validoinnille
Attribuutti required tarkistaa vain, että kenttä ei ole tyhjää. Se ei validoi sisältöä tai kenttien välistä suhdetta. Monimutkaisempaa validointia varten (esimerkiksi varmistaaksesi, että päivämäärä on tulevaisuudessa tai että kaksi kenttää ovat johdonmukaisia) käytä sen sijaan Pythonissa @api.constrains-koristetta.
Liiketoimintalogiikan koodaminen pelkästään pakollisiin kenttiin johtaa joustamattomiin kokoonpanoihin, joita on vaikea ylläpitää.
Yhteenveto
Pakollinen kenttä -attribuutti on yksi yksinkertaisimmista työkaluista Odoossa, mutta sillä on todellinen vaikutus tietosi laatuun. Hyvin käytettynä se varmistaa, että kriittiset tiedot tallennetaan aina oikeaan aikaan liiketoimintaprosesseissasi. Huonosti käytettynä se turhauttaa käyttäjiä ja luo kiertoteitä, jotka tekevät tiedoistasi vähemmän luotettavia, eivät enemmän.
Avain on ymmärtää ero mallitasoisten ja näkymätasoisten pakollisten rajoitteiden välillä, olla harkitseva niiden kenttien suhteen, jotka todella tarvitsevat valvontaa, ja miettiä eteenpäin, miten rajoite käyttäytyy automatisoiduissa työnkuluissa ja API-integraatioissa.
Olitpa sitten seuraamassa Odoo-kehittäjän opasta, tekemässä täysimittaista Odoo-kustomointiprojektia tai vain säätämässä lomaketta Odoo Studiossa, pakollinen attribuutti on syytä ymmärtää syvällisesti. Se on yksi niistä yksityiskohdista, joka erottaa puhtaan Odoo-implementoinnin sellaisesta, joka aiheuttaa päänsärkyä kuusi kuukautta käyttöönoton jälkeen.
Tarvitsetko apua Odoo-toteutuksessasi?
Yrityksessämme Dasolo autamme yrityksiä toteuttamaan, mukauttamaan ja optimoimaan Odoo:ta kaikilla liiketoimintatoiminnoilla ja monimutkaisuuden tasoilla. Olitpa sitten tarvitsemasi apua vankan tietomallin suunnittelussa, validointisääntöjen määrittelyssä tai mukautettujen moduulien rakentamisessa, tiimimme tuo jokaiseen projektiin sekä teknistä että toiminnallista asiantuntemusta.
Jos sinulla on kysymyksiä pakollisista kentistä tai mistä tahansa muusta Odoo-asetuksestasi, autamme mielellämme. Ota meihin yhteyttä ja keskustellaan siitä, mitä olet rakentamassa.