Introduktion
Hvis du nogensinde har gemt en formular i Odoo og set et felt blive rødt, har du allerede mødt krævet felt mekanismen. Det er en af de mest grundlæggende funktioner i Odoo-datamodellen og en af de enkleste måder at håndhæve datakvalitet på tværs af dine forretningsarbejdsgange.
Uanset om du konfigurerer Odoo til et salgsteam, opsætter en tilpasset model eller arbejder på et teknisk Odoo-udviklingsprojekt, vil forståelsen af, hvordan required attributten fungerer, hjælpe dig med at bygge mere pålidelige processer.
Denne guide dækker alt: hvordan feltet opfører sig i Odoo-rammen, hvordan man konfigurerer det ved hjælp af Odoo Studio eller Python-kode, hvornår man skal bruge det, og hvilke fejl man skal være opmærksom på.
Hvad er det krævede felt i Odoo
I Odoo er required-attributten en felt-niveau begrænsning, der forhindrer en post i at blive gemt, medmindre feltet indeholder en værdi. Den gælder for stort set alle Odoo-felttyper: tekstfelter, numeriske felter, valgfelter, many2one-felter, datoer og mere.
Det er en del af den grundlæggende Odoo-datamodel og er en af de mest almindeligt anvendte attributter, når man laver Odoo-tilpasninger. At indstille et felt som påkrævet er den første forsvarslinje mod ufuldstændige eller inkonsistente data i din database.
Hvordan det vises i grænsefladen
I Odoo UI er påkrævede felter visuelt adskilt fra valgfrie. Når en formular er i redigeringstilstand, viser påkrævede felter typisk en subtil visuel indikator. Når en bruger forsøger at gemme posten uden at udfylde et påkrævet felt, fremhæver Odoo feltet i rødt og viser en advarselsmeddelelse.
Denne adfærd er konsekvent på tværs af webgrænsefladen. Brugere ser øjeblikkelig, klar feedback, hvilket reducerer chancen for at indsende ufuldstændige poster.
Statisk vs. Dynamisk Påkrævet
Der er to måder at gøre et felt påkrævet i Odoo. Den første er en statisk påkrævet: feltet er altid obligatorisk, uanset hvad. Den anden er en dynamisk påkrævet: feltet bliver obligatorisk kun når visse betingelser er opfyldt, baseret på værdierne af andre felter på den samme post.
Begge tilgange bruges regelmæssigt i Odoo-udvikling. Valget afhænger af din forretningslogik.
Hvordan feltet fungerer
At forstå, hvordan required-attributten fungerer på et teknisk niveau, hjælper dig med at anvende den korrekt og fejlfinde problemer, når de opstår.
Applikationsniveau Håndhævelse
En vigtig detalje, der overrasker mange Odoo-brugere: required-attributten håndhæves på applikationsniveau, ikke på databaseniveau. Det betyder, at begrænsningen kontrolleres af Odoo ORM, når en post oprettes eller skrives, før dataene når databasen.
Der tilføjes ingen NOT NULL-begrænsning til den underliggende PostgreSQL-kolonne som standard, når du indstiller required=True på et felt. Valideringen sker i Python, inden for Odoo ORM-laget.
I praksis betyder det, at data, der indsættes direkte i databasen (omgå Odoo), ikke vil blive fanget af den krævede begrænsning. Interager altid med dine Odoo-databasefelter gennem ORM eller API for at drage fordel af denne beskyttelse.
Hvad sker der, når begrænsningen overtrædes
Når en bruger forsøger at gemme en formular med et påkrævet felt, der er efterladt tomt, sker der to ting:
- Feltet bliver rødt i grænsefladen, og Odoo viser en valideringsmeddelelse
- Gemmeoperationen blokeres, indtil feltet er udfyldt
Hvis du udløser valideringen programmatisk (for eksempel via XML-RPC API eller en serverhandling), rejser Odoo en ValidationError med en meddelelse, der angiver, hvilket påkrævet felt der mangler.
Dynamisk påkrævet ved hjælp af domæner
I Odoo-rammen kan required-attributten gøres betinget ved hjælp af udtryk på visningsniveau. I Odoo 16 og tidligere gøres dette med attrs-attributten i visnings-XML:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />I Odoo 17 og senere er syntaksen forenklet med et direkte required-udtryk på feltmærket i visningen:
<field name="x_delivery_date" required="order_type == 'delivery'" />Disse betingede regler lever i visningslaget, ikke modelaget. Dette er en vigtig skelnen: modelniveauet required=True håndhæver altid begrænsningen, mens udtryk på visningsniveau kun gælder i specifikke grænseflade-kontekster.
Interaktion med ORM og API
I Odoo ORM, når du kalder create() eller write() på en model, tjekker ORM alle felter med required=True før udførelsen af databaseoperationen. Hvis et påkrævet felt mangler eller er sat til False, rejser Odoo en ValidationError.
Dette gælder også, når der oprettes poster via XML-RPC API. Ethvert felt, der er markeret som påkrævet i modeldefinitionen, skal være angivet i datadictionaryen, der sendes til create-metoden, ellers vil opkaldet mislykkes med en fejl.
Forretningsbrugssager
Påkrævede felter findes i hele standard Odoo, og de er lige så nyttige i brugerdefinerede konfigurationer. Her er fem konkrete eksempler fra virkelige forretningsarbejdsgange, hvor det at gøre et felt påkrævet gør en reel forskel.
1. CRM: Kunde Segment Påkrævet på Leads
Et salgsteam ønsker at sikre, at hver lead tildeles et kundesegment, før det flyttes til pipeline. Uden et påkrævet felt springer salgsrepræsentanter ofte dette trin over, hvilket gør det umuligt at rapportere om leadkilder efter segment senere.
Ved at markere et brugerdefineret "Kunde Segment" valgfelt som påkrævet på CRM leadformularen sikrer teamet, at data altid bliver indsamlet på indtastningspunktet. Ingen segment, ingen gem.
2. Salg: Leveringsadresse Påkrævet på Ordrer
For virksomheder, der sender fysiske varer, er leveringsadressen kritisk. I nogle Odoo-konfigurationer er leveringsadressefeltet ikke påkrævet som standard, hvilket betyder, at ordrer kan bekræftes uden en.
At gøre leveringsadressefeltet påkrævet på salgsordreskemaet forhindrer, at ordren bliver bekræftet, før logistikteamet har de oplysninger, de har brug for. Dette eliminerer en almindelig kilde til fejl i opfyldelsesprocessen.
3. Lager: Part- eller Serienummer Påkrævet ved Modtagelse
For virksomheder, der opererer i regulerede industrier (mad, farmaceutiske produkter, elektronik), er det ikke valgfrit at spore partnumre på modtagne varer. Odoo understøtter dette nativt gennem sporingsindstillingen på produkter, som effektivt håndhæver et påkrævet part- eller serienummer under lagerbevægelser.
For tilpassede felter på kvitteringsformularer, såsom en kvalitetskontrolreference, sikrer det, at feltet er påkrævet, at lagerteamet aldrig glemmer at registrere oplysningerne under modtageprocessen.
4. Regnskab: Omkostningscenter Påkrævet på Leverandørfakturaer
Finansafdelinger har ofte brug for, at hver udgift tildeles et omkostningscenter til budgetopfølgning. Uden håndhævelse kan revisorer eller indkøbschefer efterlade feltet tomt, hvilket skaber huller i den finansielle rapportering.
Et påkrævet many2one-felt, der peger på omkostningscentermodellen, tilføjet til leverandørfakturaformularen, sikrer, at ingen faktura kan bogføres uden denne tildeling. Denne type Odoo-tilpasning er hurtig at implementere og har en direkte indvirkning på datakompletheden.
5. HR: Kontraktstype Påkrævet Før Onboarding
HR-teams, der håndterer medarbejderonboarding i Odoo, ønsker ofte at sikre, at kontraktstypen er registreret, før medarbejderoptegnelsen er afsluttet. Et påkrævet felt på medarbejderformularen forhindrer HR-teamet i utilsigtet at gemme en ufuldstændig medarbejderoptegnelse i en travl onboardingperiode.
Oprettelse eller tilpasning af feltet
Der er to hovedmåder at markere et felt som påkrævet i Odoo: ved at bruge Odoo Studio til en no-code tilgang eller ved at skrive Python-kode for fuld kontrol. Begge er gyldige afhængigt af din kontekst.
Brug af Odoo Studio
Odoo Studio er det indbyggede no-code værktøj, der lader dig konfigurere felter uden nogen udvikling. Når du åbner Studio og vælger et felt på en formular, vil du se en "Påkrævet"-vipper i feltets egenskabspanel til højre.
At aktivere denne vippe markerer feltet som påkrævet i visningen og gemmer begrænsningen på modelniveau. Dette er den hurtigste tilgang til enkle tilfælde og kræver ingen teknisk viden. Det fungerer godt for både standard Odoo-felter og tilpassede felter tilføjet gennem Odoo Studio-felter.
Begrænsningen ved Studio er, at det kun konfigurerer en statisk påkrævet begrænsning. For dynamisk påkrævet adfærd baseret på andre feltværdier skal du redigere visnings-XML direkte eller bruge den tekniske tilgang.
Teknisk tilgang: Python-felter
I et tilpasset Odoo-modul er det så enkelt at erklære et påkrævet felt som at tilføje required=True til feltdefinitionen. Dette er den standardmønster i Odoo Python-feltudvikling:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Offentlig Sektor'),
],
string='Kundesegment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Omkostningscenter',
required=True,
)Med denne tilgang håndhæves begrænsningen på modelniveau, hvilket betyder, at den gælder uanset hvilken visning eller grænseflade der bruges til at oprette posten. Den kan ikke omgås ved at få adgang til posten gennem en anden visning.
Dynamisk Påkrævet i Visning XML
Når den påkrævede begrænsning kun skal gælde under visse betingelser, skal den tilføjes på visningsniveau snarere end på modelniveau. I Odoo 16:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />I Odoo 17:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Dette er en kun visningsbegrænsning. Den er mindre striks end et påkrævet modelniveau, da den kun gælder, når posten redigeres gennem den specifikke visning, der indeholder denne definition.
Oprettelse af Påkrævede Felter via API
Hvis du bruger XML-RPC API'en til at oprette felter (som dækket i andre artikler i Odoo Data & API-samlingen), kan du indstille required når du kalder create på ir.model.fields. Dette er en del af den standard Odoo udviklerguide til programmatisk tilpasning:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Kundesegment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Dette opretter feltet og håndhæver den krævede begrænsning i ét trin, hvilket er nyttigt i automatiserede implementeringsarbejdsgange for oprettelse af felter i Odoo-scenarier.
Bedste praksis
At markere et felt som krævet virker ligetil, men at bruge det korrekt kræver lidt eftertænksomhed. Her er de praksisser, der vil spare dig tid og forhindre frustration for dine brugere.
1. Gør kun felter krævede, når de virkelig er det
At kræve for mange felter er en af de mest almindelige Odoo-konfigurationsfejl. Hvis en bruger ikke kan udfylde en formular, fordi et felt er krævet, men oplysningerne endnu ikke er tilgængelige, vil de finde alternative løsninger (som at indtaste pladsholderværdier), der korrumperer dine data.
Før du markerer et felt som krævet, spørg: er disse oplysninger altid tilgængelige på indtastningstidspunktet? Hvis svaret ikke er et klart ja, overvej at gøre det krævet på et senere tidspunkt (for eksempel ved bekræftelse frem for ved oprettelse) eller brug en dynamisk krævet i stedet.
2. Brug trinbaseret validering i stedet for altid-krævet
For arbejdsgange med flere trin, som en CRM-mulighed eller en produktionsordre, er det ofte bedre at håndhæve krævede felter på specifikke trin frem for fra starten. Dette gøres typisk gennem Python-begrænsninger eller automatiserede handlinger, der tjekker feltværdier, når posten bevæger sig til et givet trin.
Dette mønster er mere fleksibelt og brugervenligt end at gøre hvert felt krævet fra dag ét.
3. Par krævede felter med standardværdier, hvor det giver mening
Hvis et felt er krævet og har en fornuftig standardværdi for de fleste tilfælde, skal du indstille en default på feltdefinitionen. Dette reducerer friktionen for brugere, der ikke behøver at ændre standarden, samtidig med at det sikres, at feltet aldrig er tomt.
4. Foretræk modelniveau krævet for kritiske data
For data, der virkelig er kritiske (som regnskabsoplysninger, reguleringsidentifikatorer eller obligatoriske identifikatorer), håndhæve begrænsningen på modelniveau i Python frem for kun på visningsniveau. Krævede begrænsninger på visningsniveau kan omgås, hvis en post oprettes gennem API'en eller en anden visning, der ikke inkluderer begrænsningen.
5. Kommuniker krævede felter til slutbrugere
Når du tilføjer nye krævede felter til eksisterende formularer, kan brugere, der er midt i en arbejdsproces, blive overraskede. Kommuniker ændringer til dit team, før du implementerer dem, især hvis eksisterende poster kan fejle validering ved næste redigering.
6. Test med tomme og delvise data
Før du implementerer en konfiguration med nye krævede felter, skal du altid teste den fulde arbejdsproces med tomme værdier og delvise data. Dette inkluderer test via webgrænsefladen, via API'en og via eventuelle automatiserede handlinger eller integrationer, der opretter poster i Odoo. Dette er et grundlæggende skridt i enhver ansvarlig Odoo teknisk vejledning.
Almindelige faldgruber
Selv erfarne Odoo-implementatorer støder på problemer med krævede felter. At vide, hvad man skal være opmærksom på, vil spare debugging-tid og forhindre smertefulde tilbageslag.
Fælde 1: At gøre et felt krævet på en model, der allerede har poster
Hvis du tilføjer required=True til et felt på en model, der allerede indeholder tusindvis af poster, og disse poster ikke har en værdi for det felt, kan du støde på problemer, når disse poster næste gang redigeres. Brugere vil ikke være i stand til at gemme ændringer, før de udfylder det nytilføjede krævede felt.
Før du implementerer en krævet begrænsning på et eksisterende felt, skal du altid kontrollere, om eksisterende poster allerede har værdier. Hvis de ikke har, skal du køre en datamigrering for at udfylde feltet først.
Fælde 2: Forveksling af visningsniveau og modelniveau krævet
At indstille et felt som krævet i en visning (uanset om det er gennem Studio eller visnings-XML) håndhæver ikke begrænsningen på modelniveau. En post oprettet gennem API'en, en anden visning eller en import vil helt omgå visningsniveauets krævede begrænsninger.
Hvis du har brug for en hård begrænsning, skal du indstille required=True i Python-feltdefinitionen. Dette er et ofte misforstået punkt i Odoo-feltvejledningssamfundet, og det forårsager reelle datakvalitetsproblemer i produktionen.
Fælde 3: Krævede felter i automatiserede eller planlagte handlinger
Når en automatiseret handling eller planlagt handling opretter poster programmatisk, skal den give værdier for alle påkrævede felter. Hvis handlingen blev skrevet, før et påkrævet felt blev tilføjet, vil den begynde at fejle stille eller med en kryptisk fejl, efter at den påkrævede begrænsning er implementeret.
Gennemgå altid al kode til automatisk oprettelse af poster efter at have tilføjet et påkrævet felt til en eksisterende model.
Fælde 4: Importering af data, der mangler påkrævede felter
Når der importeres poster via CSV eller Odoo-importværktøjet, vil manglende påkrævede felter fra importfilen få importen til at fejle. Dette er faktisk den korrekte adfærd, men det overrasker brugere, der er vant til at importere delvise data.
Inkluder altid alle påkrævede felter i dine importskabeloner. Det er god praksis at dokumentere, hvilke felter der er påkrævet i dine retningslinjer for dataimport.
Fælde 5: Brug af påkrævet i stedet for en Python-begrænsning til kompleks validering
Attributten required tjekker kun, at et felt ikke er tomt. Den validerer ikke indholdet eller forholdet mellem felter. Til mere kompleks validering (for eksempel at sikre, at en dato er i fremtiden, eller at to felter er konsistente), brug en @api.constrains dekorator i Python i stedet.
At forsøge at indkode forretningslogik i kun påkrævede felter fører til ufleksible konfigurationer, der er svære at vedligeholde.
Konklusion
Attributten required field er et af de simpleste værktøjer i Odoo, men den har en reel indflydelse på kvaliteten af dine data. Bruges den korrekt, sikrer den, at kritisk information altid fanges på det rigtige tidspunkt i dine forretningsprocesser. Bruges den dårligt, frustrerer den brugerne og skaber løsninger, der gør dine data mindre pålidelige, ikke mere.
Nøglen er at forstå forskellen mellem modelniveau og visningsniveau påkrævede begrænsninger, at være bevidst om, hvilke felter der virkelig har brug for håndhævelse, og at tænke fremad om, hvordan begrænsningen vil opføre sig i automatiserede arbejdsgange og API-integrationer.
Uanset om du følger en Odoo-udviklerguide, laver et fuldt Odoo-tilpasningsprojekt eller blot justerer en formular i Odoo Studio, er det værd at forstå den påkrævede attribut dybt. Det er en af de detaljer, der adskiller en ren Odoo-implementering fra en, der forårsager hovedpine seks måneder efter go-live.
Har du brug for hjælp med din Odoo-implementering?
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo på tværs af alle forretningsfunktioner og niveauer af kompleksitet. Uanset om du har brug for hjælp til at designe en solid datamodel, konfigurere valideringsregler eller bygge brugerdefinerede moduler, bringer vores team både teknisk og funktionel ekspertise til hvert projekt.
Hvis du har spørgsmål om obligatoriske felter eller andre aspekter af din Odoo-opsætning, er vi glade for at hjælpe. Kontakt os og lad os tale om, hvad du bygger.