Introduktion
Har du nogensinde prøvet at gemme en formular i Odoo og fået et felt til at skifte farve? Det er systemets måde at sige: her mangler noget. Det obligatoriske-felt‑mekanisme er en grundlæggende del af Odoo‑datamodellen og en enkel men effektiv måde at sikre, at vigtige oplysninger altid bliver indsamlet.
Uanset om du sætter systemet op for et salgsteam, bygger et specialtilpasset datasæt eller arbejder teknisk med et Odoo‑projekt, gør forståelsen af attributten required det nemmere at skabe stabile og forudsigelige processer.
Denne guide tager dig igennem det væsentlige: hvordan mekanikken opfører sig i Odoo, hvordan du konfigurerer obligatoriske felter via Studio eller i Python, hvornår det giver mening at bruge dem, og hvilke fejl du bør undgå.
Hvad betyder et obligatorisk felt i Odoo?
I Odoo er required en egenskab på feltet, der forhindrer, at en post kan gemmes uden en værdi i det pågældende felt. Den gælder for stort set alle felttyper: tekst, tal, valgfelter, many2one‑relationer, datoer osv.
Det er en indbygget del af datamodellen og et af de mest brugte værktøjer ved tilpasninger. At markere et felt som obligatorisk er ofte det første skridt mod at forhindre manglende eller inkonsistente data i din Odoo‑installation.
Hvordan det ser ud i brugerfladen
I Odoo UI skiller obligatoriske felter sig typisk ud. Når formularen er i redigering, viser systemet en visuel indikator. Hvis brugeren forsøger at gemme uden at udfylde feltet, fremhæves det og der vises en valideringsmeddelelse.
Denne umiddelbare feedback i webklienten hjælper brugerne med at rette fejl med det samme og mindsker sandsynligheden for ufuldstændige poster.
Statisk kontra dynamisk obligatorisk
Der er to hovedtilgange: et felt kan være permanent obligatorisk (statisk), eller det kan kun blive påkrævet under bestemte betingelser (dynamisk), afhængigt af værdier i andre felter på samme post.
Begge metoder bruges ofte — valget styres af forretningsreglerne og hvor fleksibelt oplæsningen skal være.
Hvordan feltet fungerer i praksis
Teknisk forståelse gør det lettere at bruge required korrekt og løse problemer, når de opstår.
Hvad der håndhæves hvor
En vigtig detalje: required håndhæves i Odoo‑applikationen, ikke automatisk i databasen. Det betyder, at kontrollen udføres af Odoo‑ORM'en i det øjeblik, en post oprettes eller opdateres, før data skrives til PostgreSQL.
Der bliver som udgangspunkt ikke oprettet en NOT NULL‑begrænsning i databasen, når du sætter required=True på et felt. Valideringen ligger som Python‑logik i ORM‑laget.
I praksis betyder det også, at hvis nogen skriver direkte i databasen uden om Odoo, så bliver den obligatoriske regel ikke håndhævet. Derfor bør alle ændringer af Odoo‑data ske via ORM eller API.
Hvad sker der, når reglen brydes
Når en bruger forsøger at gemme en formular uden at have udfyldt et obligatorisk felt, sker der typisk to ting:
- Feltet markeres visuelt, og Odoo viser en fejlmeddelelse
- Gemningen afvises, indtil feltet er udfyldt
Hvis valideringen kaldes programmatisk (fx via XML‑RPC eller en serveraktion), kaster Odoo en ValidationError med oplysninger om, hvilket felt der mangler.
Dynamisk obligatorisk med betingelser i visningen
I Odoo kan du lave betinget obligatorisk adfærd i viewlaget. I ældre versioner anvendte man attrs i view‑XML'en til at styre denne opførsel:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />I nyere versioner er syntaksen mere direkte, så krav kan angives som en udtryk i felt‑tagget:
<field name="x_delivery_date" required="order_type == 'delivery'" />Husk, at disse regler lever i viewlaget — de gælder kun, når brugeren arbejder via den specifikke visning. Et modelniveau‑required=True er derimod håndhævet uanset GUI.
Hvordan ORM og API interagerer med kravet
Når du kalder create() eller write() via ORM'en, kontrolleres alle modelfelter med required=True først. Mangler et felt eller er det sat til False, kastes en ValidationError.
Det gælder også for poster oprettet via XML‑RPC/API: alle felter markeret som obligatoriske i modellen skal indgå i data, ellers fejler opkaldet.
Når det gør en forskel i virksomheden
Her er fem konkrete eksempler fra daglig praksis, hvor obligatoriske felter gør en målbar forskel i arbejdsgangene.
1. CRM: Segment på leads
Salgsteams vil ofte sikre, at hver lead klassificeres i et kundesegment, før den går videre i salgsprocessen. Uden et obligatorisk segmentfelt bliver denne opgave nemt sprunget over, hvilket gør efterfølgende rapportering upræcis.
Ved at gøre et segmentfelt obligatorisk på lead‑formularen sikrer organisationen, at data indsamles ved kilden — ingen segmentværdi betyder ingen gemning.
2. Salg: Leveringsadresse på ordrer
For virksomheder, der sender fysiske varer, er leveringsadressen essentiel. I nogle standardopsætninger er adressen ikke obligatorisk, så ordrer kan bekræftes uden de nødvendige leveringsoplysninger.
Gør leveringsadressen obligatorisk på salgsordren, så ordren ikke kan bekræftes, før logistikken har de oplysninger, de behøver — det reducerer fejl i leveringsprocessen.
3. Lager: Lot‑ eller serienummer ved modtagelse
I regulerede brancher er sporbarhed afgørende. Odoo understøtter sporing via produktindstillinger, som sikrer, at et lot‑ eller serienummer registreres ved varebevægelser.
For specialfelter på modtageformularer, fx reference til kvalitetskontrol, sikrer et obligatorisk felt at lagerpersonalet ikke glemmer at registrere vigtige oplysninger.
4. Regnskab: Omkostningssted på leverandørfakturaer
Økonomiafdelinger kræver ofte, at alle udgifter tilknyttes et omkostningssted for korrekt budgetstyring. Uden håndhævelse efterlades mange bilag ufuldstændige.
Et obligatorisk many2one‑felt til omkostningsstedet på leverandørfakturaen sikrer, at en faktura ikke kan bogføres uden denne information — en lille ændring med stor effekt på rapporteringen.
5. HR: Kontrakttype før onboarding
Når HR afslutter en nyansættelse, skal kontrakttypen ofte være fastlagt, før medarbejderposten anses for færdig. Et obligatorisk felt forhindrer, at HR gemmer ufuldstændige medarbejderoprettelser i travle perioder.
Sådan opretter eller tilpasser du et obligatorisk felt
Der findes to hovedmåder at gøre et felt obligatorisk i Odoo: no‑code via Odoo Studio eller via Python i et modul. Valget afhænger af behov for fleksibilitet og kontrol.
Brug af Odoo Studio
Odoo Studio er værktøjet til hurtige ændringer uden udvikling. Vælger du et felt i en formular, vises en 'Obligatorisk'‑knap i feltets egenskaber, som du blot kan slå til.
Når knappen aktiveres, markeres feltet som obligatorisk i visningen og opdateres i modellen. Det er den hurtigste metode til simple behov og virker for både standardfelter og brugerdefinerede felter oprettet i Studio.
Begrænsningen ved Studio er, at det ofte kun opretter en statisk, view‑baseret regel. Skal kravet være betinget, kræver det ofte direkte redigering af view‑XML eller teknisk arbejde.
Teknisk tilgang: felter i Python
I et custom modul angiver du et obligatorisk felt ved at tilføje required=True i feltdefinitionen. Det er standardmønstret i Odoo‑udvikling:
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,
)Med denne metode håndhæves kravet på modelniveau — uanset hvilken visning eller API der bruges til at oprette posten — og det kan ikke omgås via en anden GUI.
Dynamisk obligatorisk i view‑XML
Hvis kravet kun skal gælde under bestemte betingelser, placeres det i viewlaget. I ældre Odoo‑versioner bruger man:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />I nyere versioner er det ofte simplere:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Denne løsning er dog kun gældende for den konkrete visning og er derfor mindre skrappet end en modelniveau‑obligation.
Oprettelse af obligatoriske felter via API
Du kan også oprette felter og sætte dem som obligatoriske programmatisk via XML‑RPC ved at lave en post i ir.model.fields. Det er praktisk ved automatiserede deployment‑flows:
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',
}]
)På den måde oprettes feltet og kravet på én gang — nyttigt ved automatiserede installationer eller når flere miljøer skal have samme konfiguration.
Gode arbejdsmetoder
At gøre et felt obligatorisk er enkelt, men kræver omtanke for ikke at skabe unødvendigt bøvl for brugerne. Følgende anbefalinger hjælper dig med at undgå hyppige problemer.
1. Gør kun felter obligatoriske, når det virkelig er nødvendigt
For mange obligatoriske felter er en klassisk fejl. Hvis brugere ikke kan færdiggøre en formular fordi et felt er påkrævet men info ikke er tilgængelig, vil de finde genveje — fx indsætte placeholder‑værdier — og så bliver dataene ugyldige.
Spørg altid: er denne oplysning tilgængelig ved indtastning? Hvis ikke, overvej at gøre feltet obligatorisk senere i processen (fx ved bekræftelse) eller brug en betinget regel.
2. Brug stages/tilstande i stedet for altid‑på krav
I workflows med flere trin er det ofte smartere at tvinge felter ved bestemte stadier i stedet for fra start. Det kan håndteres med Python‑constraints eller automatiske handlinger, der tjekker værdier, når posten skifter til en given fase.
Det er en langt mere brugervenlig løsning end at gøre alt obligatorisk fra oprettelse.
3. Kombiner obligatoriske felter med fornuftige standardværdier
Hvis et felt oftest har en åbenbar standard, sæt en default. Det mindsker friktion for brugere og sikrer samtidig, at feltet aldrig står tomt.
4. Brug model‑niveau krav til kritiske data
Værdier, der er forretningskritiske (fx regnskabsfelter eller lovpligtige identifikatorer), bør håndhæves i modellen med required=True. View‑krav kan omgås via API eller alternative visninger.
5. Informér brugerne om nye obligatoriske felter
Når du føjer nye obligatoriske felter til eksisterende formularer, kan det overraske folk midt i deres arbejde. Informér teamet før deployment, især hvis eksisterende poster kan blive blokeret ved næste redigering.
6. Test med tomme og delvise datasæt
Test altid hele processen med tomme og delvise data før udrulning. Inkluder test via web UI, API og alle integrationer, der opretter poster i Odoo — det er essentielt for stabile leverancer.
Typiske faldgruber
Selv rutinerede Odoo‑implementere støder på problemer med obligatoriske felter. Her er de mest almindelige fejl, som ofte skaber hovedbrud.
Faldgrube 1: Gøre et felt obligatorisk på en model, der allerede har data
Hvis du sætter required=True på et felt i en model, hvor tusindvis af poster allerede findes uden den værdi, kan brugere ikke længere gemme redigeringer uden først at udfylde feltet.
Før du deployer et krav på et eksisterende felt, tjek om data allerede findes. Mangler data, lav en migration, der udfylder feltet automatisk eller via en målrettet opdatering.
Faldgrube 2: Forveksling mellem view‑ og modelniveau
At sætte et felt som obligatorisk i en view (via Studio eller XML) håndhæver ikke kravet i modellen. Poster oprettet gennem API, en anden view eller en import kan omgå denne regel.
Har du brug for et hårdt krav, sæt required=True i Python‑feltdefinitionen — det er et punkt, mange undervurderer og som ofte skaber datakvalitetsproblemer i produktion.
Faldgrube 3: Obligatoriske felter i automatiserede handlinger
Når automatiske eller planlagte handlinger skaber poster programmatisk, skal de udfylde alle obligatoriske felter. Hvis scriptet er skrevet før et felt blev obligatorisk, vil det begynde at fejle eller give kryptiske fejlmeddelelser.
Gennemgå altid automatiske oprettelsesrutiner efter tilføjelse af nye obligatoriske felter.
Faldgrube 4: Import af data uden obligatoriske felter
Ved CSV‑import eller brug af Odoos importværktøj vil manglende obligatoriske felter få importen til at fejle. Det kan overraske brugere, der forventer at importere delvise datasæt.
Medtag altid alle obligatoriske felter i importskabeloner, og dokumentér klart hvilke felter der er påkrævede i dine importinstrukser.
Faldgrube 5: Bruger required i stedet for Python‑constraints til kompleks validering
Attributten required kontrollerer kun, at et felt ikke er tomt — den tjekker ikke logik eller relation mellem felter. For avancerede valideringer (fx at en dato skal være i fremtiden, eller at to felter skal være kompatible), brug @api.constrains i Python.
Forsøg på at presse forretningslogik ind i obligatoriske felter fører til ufleksible og svære at vedligeholde løsninger.
Opsummering
Obligatoriske felter er et simpelt, men kraftfuldt redskab i Odoo. Når de bruges rigtigt, sikrer de, at kritiske oplysninger fanges præcist, hvor det giver mest værdi. Bruges de forkert, skaber de frustration og dårlige data.
Det vigtigste er at kende forskellen mellem model‑ og view‑niveau, kun gøre felter obligatoriske når det er nødvendigt, og tænke over konsekvenserne for automatiseringer og API‑integrationer.
Uanset om du følger en udviklervejledning, laver en større tilpasning eller blot justerer en formular i Studio, lønner det sig at forstå required godt. Det er ofte detaljen, der adskiller en robust implementering fra et system, som skaber problemer efter go‑live.
Har I brug for hjælp til jeres Odoo-implementering?
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo på tværs af funktioner og kompleksitet. Uanset om I har brug for assistance til datamodeldesign, valideringsregler eller udvikling af specialmoduler, kombinerer vores team funktionel indsigt med teknisk erfaring.
Har I spørgsmål til obligatoriske felter eller andre dele af jeres Odoo‑opsætning, står vi klar til at hjælpe. Kontakt os og lad os tage en snak om, hvad I bygger.