Readonly-fält i Odoo är en enkel idé vid första anblicken — ett synligt, icke-redigerbart fält — men deras roll sträcker sig långt in i systemets arbetsflöden, säkerhet och rapportering.
Oavsett om du som slutanvändare undrar varför vissa fält är nedtonade, eller om du som utvecklare vill styra fältbeteende i en anpassning, ger den här guiden en helhetsbild så att du vet vad som händer bakom kulisserna.
Att förstå readonly-varianten är avgörande för tillförlitliga processer: rätt använd bevarar dataintegritet, minskar fel och förbättrar användarupplevelsen i vardagsarbetet.
Den här genomgången tar både verksamhetsnära exempel och tekniska implementationer — så oavsett om du konfigurerar Odoo utan kod eller bygger modulär logik, hittar du relevanta råd här.
Vad betyder readonly-fält i Odoo
Ett readonly-fält i Odoo visar information men tillåter inte direkt inmatning i gränssnittet. Värdet kan vara synligt men inte redigerbart av slutanvändaren.
I formulärvyer syns sådana fält vanligen som vanlig text istället för som fält där man kan skriva. Beroende på tema kan de också uppfattas som nedtonade eller platta jämfört med aktiva inputfält.
Readonly-beteende kan appliceras på två nivåer i Odoo-arkitekturen:
- På modellnivå (Python/ORM): fältet är alltid readonly i alla vyer och sammanhang
- På vy-nivå (XML): fältet är readonly i en specifik vy eller under särskilda villkor
Skillnaden är väsentlig: en modellnivå-inställning blockerar all skrivning från användargränssnittet och många programgränssnitt, medan en vy-nivå-inställning bara begränsar redigering i just den vyn och i UI-flödet.
Readonly är inte en egen fälttyp — det är en egenskap som går att sätta på alla vanliga Odoo-fälttyper: Char, Integer, Float, Many2one, Date med flera. Det är ett grundläggande verktyg för att styra fältbeteende.
Hur readonly-attributet fungerar i praktiken
För att förstå praktiska konsekvenser måste du se både modellens (ORM/Python) och vy-lagrets (XML) perspektiv.
Readonly på ORM-nivå
I Odoo:s ORM deklarerar du ett fält som permanent readonly i Python-modellen. Det är ofta fallet för beräknade fält: du anger readonly=True i fältdefinitionen, och systemet tillåter inte att användare ändrar värdet via UI.
Den här typen av readonly är en del av Odoo:s fält-API och gäller globalt oberoende av vilken vy som används.
Readonly styrt av dokumentets status
Ett vanligt mönster är att låsa fält beroende på dokumentets status — till exempel att fälten blir låsta när ett dokument går från utkast till bekräftat. Det är så standardmoduler håller historiken stabil.
Tidigare versioner använde attrs-dictionary i XML för villkorliga readonly-regler; nyare versioner (från Odoo 17) erbjuder mer koncisa inlineuttryck på fältnivå som gör samma sak enklare att läsa.
Slutsatsen är densamma i båda fallen: fält är redigerbara i utkaststadiet men låses när dokumentet avancerar, vilket är centralt för säkra arbetsflöden.
Beräknade fält och readonly
Fält med compute-metod är normalt readonly eftersom deras värde härleds automatiskt från andra fält. Systemet antar att användaren inte ska skriva över beräknade resultat direkt.
Om du dessutom vill lagra beräkningen i databasen sätter du store=True. Storing är vanligt för prestanda och för att kunna filtrera och sortera direkt i databasen.
Göra ett beräknat fält skrivbart
Vill du att ett beräknat fält ändå ska kunna få manuella värden måste du definiera en inverse-metod. Inverse berättar hur systemet ska hantera skrivningar till fältet — utan den förblir fältet readonly.
När företag har nytta av readonly-fält
Readonly-fält dyker upp i alla Odoo-moduler. Här är fem konkreta affärsfall där de skyddar data och processer.
1. CRM: låsa vunna/förlorade affärer
I CRM är förväntad intäkt och stängningsdatum redigerbara under bearbetning, men låses när en affär markeras som vunnen eller förlorad för att bevara en korrekt historik.
Det förhindrar att någon efterjusterar siffror i efterhand och därigenom snedvrider försäljningsrapporter och pipeline-analys.
2. Försäljning: skydda bekräftade orderrader
När en offert blir en bekräftad order låses orderraderna — produkter, kvantiteter och priser kan inte ändras efter kundbekräftelse.
Om ändring måste ske görs det genom att återställa till utkast, vilket lämnar spår av åtgärden och minskar risken för oavsiktliga ändringar.
3. Lager: blockerade kvantiteter efter validering
I lagerhantering låses de faktiskt genomförda kvantiteterna efter validering av leverans eller mottagning. Det säkrar lagerbalansen och värdering mot vad som faktiskt rört sig i varuhuset.
Att kunna ändra kvantiteter i efterhand utan dokumentation riskerar att korrupta lagerdata över flera platser.
4. Redovisning: postade verifikationer
När en verifikation är postad blir raderna readonly — både av redovisningsprinciper och av legala skäl i många länder.
Att tillåta efterhandsändringar skulle äventyra bokslutets trovärdighet och skapa regelefterlevnadsrisker.
5. Produktion: avslutade arbetsorder
När en arbetsorder markeras som färdig låses tid- och produktionsuppgifter för att säkra produktionshistorik som används i kostnadsberäkningar och nyckeltal.
Skapa och anpassa ett readonly-fält i Odoo
Det finns två huvudvägar för att införa readonly i Odoo: Odoo Studio för snabba, kodfria ändringar eller Python/XML för full kontroll.
Använda Odoo Studio
Med Odoo Studio kan administratörer lägga till eller ändra readonly-egenskaper utan att skriva kod.
- Starta Odoo Studio via menyikonen (penna)
- Gå till formulärvyn där fältet ska konfigureras
- Klicka på fältet du vill ändra
- I egenskapsmenyn till höger slå på alternativet "Readonly"
- Spara och avsluta Studio
Studio stödjer också villkorlig readonly via uttryck — exempelvis lås fält när ett statusfält har ett visst värde — allt utan en rad kod.
Studio är ofta bästa valet för konsulter och administratörer som vill införa regler snabbt och säkert. Ändringar sparas i databasen och påverkas inte av moduluppdateringar.
Använda Python för teknisk anpassning
Utvecklare sätter readonly direkt i fältdefinitionen i Python-modellen när de bygger moduler.
Du kan ange readonly=True som en statisk parameter för permanenta begränsningar, eller använda states-parameter för att styra när fältet ska vara skrivbart respektive låst beroende på dokumentets status.
Denna metod är lämplig när du lägger till logik nära datamodellen — särskilt vid anpassningar av standardmodeller inom större utvecklingsprojekt.
Använda XML-vyattribut
Vill du begränsa redigering i en viss vy lägger du till readonly-attributet i fält-taggen i vy-XML:en.
Fördelen med vy-nivå readonly är flexibilitet: samma fält kan bete sig olika i olika vyer utan att ändra modellens definition — praktiskt när du vill styra UI-beteende lokalt.
I Odoo 17 är inlinevillkor för readonly ofta renare och mer lättlästa jämfört med äldre attrs-syntax; båda metoderna fungerar beroende på version.
Riktlinjer och rekommendationer
Bra användning handlar om att sätta readonly på rätt nivå och av rätt anledning. Nedan finns de viktigaste råden från konsultperspektiv.
1. Föredra vy-nivå när kontexten varierar
Om fältet bara ska vara låst i vissa stater eller vyer, sätt readonly i vyn. Det bevarar flexibiliteten i datamodellen och tillåter backend-processer eller integrationer att uppdatera fältet vid behov.
2. Anpassa readonly efter dokumentets livscykel
Lås fält i de steg där vidare redigering riskerar att skapa problem. När readonly följer arbetsflödet blir systemet förutsägbart och lättare för användarna att förstå.
3. Testa över användarroller
Readonly kan interagera oväntat med behörigheter. Testa som både vanlig användare och som administratör så att beteendet blir korrekt för varje roll.
4. Kombinera readonly med required vid behov
I flerstegsformulär är det vanligt att ett fält är obligatoriskt i utkast men readonly senare. Kombinera attributen i vy-XML för att säkerställa att data fås in i rätt steg.
5. Dokumentera varför ett fält är readonly
Lämna kommentarer i koden om affärsregeln bakom en readonly-inställning — framtida utvecklare behöver förstå affärslogiken, inte bara tekniken.
6. Använd Studio för snabba, uppgraderingståliga ändringar
Studio är smidigt för enkla behov. Spara Python-anpassningar till fall där Studio inte räcker, t.ex. komplexa korsfältvillkor eller avancerade invers-metoder.
Vanliga fallgropar att undvika
Även rutinerade användare snubblar över vanliga problem med readonly-fält. Här är de som ofta orsakar huvudbry.
Förväxla inte vy-nivå readonly med säkerhetsgräns
Readonly i vyn är bara ett UI-skydd — API-anrop, XML-RPC eller server-skrivningar kan fortfarande ändra fältet. Om du behöver blockera alla skrivningar, använd ORM-nivå readonly eller access rules.
Göra fält permanent readonly när en villkorsbaserad lösning vore bättre
Att sätta ett fält permanent readonly kan blockera legitima jobbflöden som t.ex. återställning till utkast för korrigeringar. Tänk igenom hela livscykeln innan du väljer permanent.
Glömma onchange-metoder
En onchange kan fortfarande försöka skriva till ett readonly-fält, vilket skapar förvirring när fältet verkar uppdateras men sedan blockeras eller revertas. Säkerställ att dina onchange-logiker tar readonly i beaktande.
Inkonsekvent readonly över olika vyer
Ett fält som är låst i formulärvyn kan vara redigerbart i list- eller kanban-vyer om du inte upprepar regeln. Kontrollera alla vyer där fältet visas.
Biverkningar vid arv av standardmodeller
När du ärver en standardmodell och sätter readonly=True på ett befintligt fält påverkar det alla vyer där fältet används — se till att det inte bryter standardfunktionalitet eller andra anpassningar.
Sammanfattning
Readonly-fält är ett grundläggande verktyg i Odoo för att styra användare genom processer, skydda data och upprätthålla affärsregler utan att förlita sig på utbildning.
Nyckeln ligger i att välja modell- eller vy-nivå med omsorg och att matcha villkoren mot hur teamet faktiskt arbetar. En genomtänkt datamodell använder readonly vid rätt tidpunkter i dokumentets livscykel.
Oavsett om du använder Studio för enkla ändringar eller kodar i Python och XML för mer avancerade lösningar så är syftet alltid detsamma: visa information men skydda den från oavsiktliga ändringar.
Readonly kanske inte är det mest glamorösa ämnet i Odoo-anpassning — men de påverkar användbarhet och datakvalitet mer än man tror.
På Dasolo hjälper vi företag att införa, anpassa och optimera Odoo över alla moduler och branscher. Behöver ni hjälp med fältkonfiguration, arbetsflödesdesign eller förbättring av datamodellen så kan vårt team stötta er. Kontakta oss och berätta om ditt projekt.