Introduktion
Har du någon gång sparat ett formulär i Odoo och sett ett fält lysa rött? Då har du råkat ut för Odoos mekanism för obligatoriska fält. Det är en grundläggande funktion i datamodellen som hjälper dig fånga nödvändig information redan vid datainmatningen.
Oavsett om du sätter upp Odoo för säljavdelningen, skapar egna modeller eller utvecklar anpassade moduler, ger kunskap om attributet required tryggare och mer förutsägbara arbetsflöden.
Den här guiden tar upp allt du behöver veta: hur attributet beter sig i Odoo‑ramverket, hur du ställer in det via Odoo Studio eller med Python, när det bör användas och vilka misstag du bör undvika.
Vad betyder "obligatoriskt fält" i Odoo?
I Odoo är required ett fältdatums‑villkor som förhindrar att en post sparas om fältet är tomt. Det kan tillämpas på nästan alla fälttyper: text, tal, urval, many2one, datum osv.
Det är en integrerad del av Odoos datamodell och ett av de vanligaste verktygen vid anpassningar. Att markera ett fält som obligatoriskt är ofta första steget för att skydda datakvaliteten i systemet.
Hur det syns i gränssnittet
I användargränssnittet visas obligatoriska fält tydligt. När ett formulär sparas utan ett ifyllt obligatoriskt fält markerar Odoo fältet visuellt (ofta i rött) och visar ett felmeddelande så att användaren kan rätta till det.
Denna direkta återkoppling i webbgränssnittet gör att felaktiga eller ofullständiga poster fångas upp tidigt och minskar risken för trasiga processer längre fram.
Statisk kontra dynamisk obligatoriskhet
Det finns två huvudvarianter: ett statiskt obligatoriskt fält som alltid måste fyllas i, och ett dynamiskt som bara kräver värde när vissa villkor uppfylls — till exempel baserat på andra fält i samma post.
Båda varianterna används ofta; valet styrs av företagets logik och hur flexibelt du behöver att formulären är.
Hur mekanismen fungerar
Teknisk förståelse för required hjälper dig använda det rätt och snabbare felsöka om problem uppstår.
Tillämpning på applikationsnivå
En viktig detalj som överraskar många: required kontrolleras av Odoo‑applikationen, inte automatiskt av databasen. Valideringen utförs av ORM‑lagret i Python innan något skickas till PostgreSQL.
Det betyder att Odoo inte per automatik lägger till en NOT NULL‑constraint på databaskolumnen när du sätter required=True. Kontroll görs i applikationslagret.
I praktiken innebär det att om någon skriver direkt i databasen utan att gå via Odoo (vilket inte rekommenderas) så kommer inte obligatoriska fält att valideras. Använd alltid ORM eller API för att säkerställa dataskyddet.
Vad som händer när regeln bryts
Om en användare försöker spara utan att fylla i ett obligatoriskt fält händer två saker:
- Fältet markeras tydligt i gränssnittet och ett valideringsmeddelande visas
- Sparåtgärden avbryts tills fältet fylls i
Gör du ändringen via API eller serverkod kommer Odoo att kasta en ValidationError med information om vilket fält som saknas.
Dynamisk obligatoriskhet med domäner/uttryck
I Odoo kan obligatoriska fält göras villkorade i vyerna. I äldre versioner används ofta attrs i XML‑vyer för detta ändamål:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />I nyare Odoo‑versioner finns enklare syntax direkt i fälttaggen för uttryck som styr obligatoriskhet:
<field name="x_delivery_date" required="order_type == 'delivery'" />Viktigt: sådana regler lever i vy‑lagret, inte modell‑lagret. Ett modellnivå‑required=True gäller alltid, medan vyuttrycken bara påverkar det specifika gränssnitt där de finns.
Interaktion med ORM och API
När du anropar create() eller write() kontrollerar ORM alla fält med required=True innan databasen uppdateras. Om fält saknas kommer en ValidationError att kastas.
Samma regler gäller vid skapande via XML‑RPC eller andra API‑anrop: obligatoriska fält måste ingå i datastrukturen eller så misslyckas anropet.
När företag använder obligatoriska fält
Exempel från verkliga affärsflöden visar varför obligatoriska fält gör skillnad i dagligt arbete.
1) CRM: Obligatorisk kundsegmentering för leads
Säljteamen behöver ofta att varje lead får en segment‑märkning för att senare kunna analysera pipeline och källor. Utan obligatoriskt fält hoppar säljare över steget och rapporteringen blir missvisande.
Genom att göra ett 'Kundsegment'‑fält obligatoriskt försäkrar du att informationen fångas vid inmatning och att inga leads lämnas oklassificerade.
2) Försäljning: Leveransadress obligatorisk på order
För företag som skickar fysiska varor är leveransadressen avgörande. Om adressfältet inte är obligatoriskt kan order gå vidare utan nödvändig information.
Ett obligatoriskt leveransadressfält hindrar att order bekräftas innan logistik har den data de behöver, vilket minskar fel i leveranskedjan.
3) Lager: Serienummer/lots nr obligatoriskt vid mottagning
I reglerade branscher måste mottagna varor spåras med lot‑ eller serienummer. Odoo stödjer detta via spårningsinställningar som praktiskt taget gör fältet obligatoriskt vid lagerrörelser.
För egna fält i mottagningsformulär, till exempel referenser för kvalitetskontroll, ser ett obligatoriskt fält till att lagret alltid registrerar informationen.
4) Redovisning: Kostnadsställe obligatoriskt på leverantörsfakturor
Ekonomiavdelningar behöver ofta att alla kostnader kopplas till ett kostnadsställe för budgetuppföljning. Om fältet lämnas tomt uppstår luckor i rapporteringen.
Ett obligatoriskt many2one‑fält till kostnadsställe på fakturan ser till att ingen faktura kan bokföras utan korrekt fördelning.
5) HR: Anställningsform obligatorisk innan onboarding slutförs
Vid onboarding vill HR oftast ha anställningsform registrerad innan medarbetarposten avslutas. Ett obligatoriskt fält förhindrar att ofullständiga personalposter sparas under en hektisk onboarding.
Skapa eller anpassa obligatoriska fält
Det finns två huvudsätt att göra fält obligatoriska: med Odoo Studio (no‑code) eller genom Python i en modul (kod). Valet beror på hur mycket kontroll du behöver.
Göra det i Odoo Studio
Odoo Studio låter dig ändra formulär utan att koda. Väljer du ett fält i Studio finns en enkel 'Obligatorisk'‑brytare i egenskapspanelen.
Aktiverar du den kommer fältet att markeras som obligatoriskt i vyn och sparas i modellkonfigurationen. Det är snabbt och kräver ingen teknisk kunskap—bra för enkla fall och egna fält skapade genom Studio.
Nackdelen är att Studio främst skapar statiska begränsningar. För dynamisk obligatoriskhet baserad på andra fält krävs att du redigerar vy‑XML eller använder teknisk kod.
Teknisk metod: Pythonfält
I en anpassad modul anger du required=True i fältdefinitionen för att göra ett fält obligatoriskt på modellnivå. Det är standardmönstret i Odoo‑utveckling.
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 modellnivå‑required gäller regeln oavsett vilket gränssnitt eller vilken vy som används för att skapa posten — det är en hårdare garanti för dataintegritet.
Dynamisk obligatoriskhet i vy‑XML
När ett fält bara ska vara obligatoriskt i vissa situationer lägger du regeln i vyn istället för i modellen. I Odoo 16 används attrs:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />I nyare versioner (Odoo 17+) kan uttrycket skrivas mer direkt:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Kom ihåg att vy‑begränsningar bara gäller i den vy där de finns — de är inte lika tvingande som modellnivå‑required.
Skapa obligatoriska fält via API
När du skapar fält programatiskt via XML‑RPC kan du sätta required i anropet mot ir.model.fields. Det är praktiskt för automatiserade deployment‑script.
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',
}]
)Detta skapar fältet och sätter obligatorisk‑egenskapen i ett steg—bra när du automatiserar anpassningar i flera miljöer.
Rekommenderade arbetsmetoder
Att markera fält som obligatoriska är enkelt, men görs bäst med eftertanke. Följande rutiner minskar risken för problem i drift.
1) Kräv bara fält som verkligen behövs
Att göra för många fält obligatoriska är en vanlig konfigurationsmiss. Om användarna inte har informationen vid inmatning kommer de hitta sätt att kringgå regeln (t.ex. fylla i 'placeholder'‑värden) och datakvaliteten försämras.
Fråga alltid: är uppgiften alltid tillgänglig vid inmatning? Om svaret är nej, överväg att kräva fältet senare i processen eller använd dynamisk obligatoriskhet.
2) Validera i steg i stället för att kräva allt från start
I arbetsflöden med flera steg är det ofta bättre att kontrollera fälten vid specifika stadier (t.ex. vid bekräftelse) istället för att göra dem obligatoriska direkt. Det kan lösas via Python‑constraints eller automatiska åtgärder som körs vid statusändring.
Det gör systemet mer användarvänligt och flexibelt.
3) Kombinera obligatoriska fält med relevanta standardvärden
Om ett fält oftast har ett förväntat värde, sätt ett default för att minska friktionen. Då slipper användaren ändra något i vanliga fall, samtidigt som fältet aldrig blir tomt.
4) Använd modellnivå‑required för kritisk data
För affärskritisk information — t.ex. i redovisning eller regulatoriska fält — bör du använda required=True i Python så att regeln gäller oavsett vy eller API‑anrop.
Vy‑nivå kräver kan lätt kringgås och ger inte samma garanti för dataintegritet.
5) Informera användarna vid ändringar
När du lägger till obligatoriska fält i befintliga formulär kan användare som redan arbetar med poster bli överraskade. Meddela teamet innan utrullning, särskilt om gamla poster kan bryta vid nästa redigering.
6) Testa med tomma och ofullständiga dataset
Vanliga fallgropar
Innan du rullar ut nya obligatoriska fält, testa flödet med både tomma och ofullständiga värden — via webben, API:er och alla integrationer som skapar poster. Det minimerar oväntade fel i produktion.
Även erfarna Odoo‑implementerare snubblar över problem med obligatoriska fält. Här är vad du bör undvika för att slippa onödigt felsökande.
Fallgrop 1: Göra ett fält obligatoriskt i en modell med redan existerande poster
Om du sätter required=True på en modell som redan innehåller tusentals poster utan värde för det fältet, kommer användare inte kunna spara ändringar förrän alla poster uppdaterats. Det leder ofta till driftstopp.
Innan du inför en ny hård constraint, kontrollera befintliga data och kör en migrering för att fylla fältet där det saknas.
Fallgrop 2: Förväxla vy‑ och modellnivå
Att markera ett fält som obligatoriskt enbart i vyn (via Studio eller XML) innebär inte att det är obligatoriskt för API‑anrop eller andra vyer. Behöver du en säker regel, sätt den i Python‑fältet.
Det här missförståndet är en vanlig orsak till datainkonsistens i produktion.
Fallgrop 3: Automatiska och schemalagda åtgärder som inte fyller obligatoriska fält
Automatiska script eller schemalagda jobb som skapar poster måste kompletteras när du lägger till obligatoriska fält. Annars börjar de misslyckas med kryptiska felmeddelanden.
Gå igenom all programmatisk postskapande kod efter att du introducerat ett nytt obligatoriskt fält.
Fallgrop 4: Importer som saknar obligatoriska fält
Vid CSV‑import eller via Odoos importverktyg kommer filer som saknar obligatoriska fält att misslyckas — detta är korrekt men chockerande för användare som förväntat sig att importera ofullständig data.
Inkludera alltid obligatoriska fält i importmallar och dokumentera vilka fält som måste finnas med.
Fallgrop 5: Använd inte required som ersättning för mer avancerad validering
required kontrollerar bara att ett fält inte är tomt. Om du behöver komplexare regler — till exempel datumvalidering eller beroenden mellan fält — använd @api.constrains i Python.
Sammanfattning
Obligatoriska fält är ett enkelt men kraftfullt verktyg i Odoo. Använd rätt så förbättrar de datakvaliteten och säkerställer att viktiga uppgifter fångas in i rätt ögonblick. Använd fel så skapar de frustration och arbetsomgånger som underminerar datan.
Nyckeln är att förstå skillnaden mellan modell‑ och vy‑constraints, tänka igenom vilka fält som faktiskt behöver vara tvingande och förutse effekter på automatiserade arbetsflöden och integrationer.
Oavsett om du följer en utvecklarguide, gör en större anpassning eller bara justerar ett formulär i Odoo Studio, är det värt att sätta sig in i hur required fungerar. Det är en liten detalj som ofta avgör om en implementation fungerar smidigt i längden.
Behöver du hjälp med din Odoo‑implementation?
På Dasolo hjälper vi företag att implementera, anpassa och optimera Odoo för alla delar av verksamheten — från modellarkitektur till valideringsregler och skräddarsydda moduler. Vi kombinerar teknisk och funktionell kompetens för att leverera robusta lösningar.
Har du frågor om obligatoriska fält eller andra delar av din Odoo‑lösning så hjälper vi gärna till. Kontakta oss så tar vi ett samtal om vad du vill bygga.