Readonly‑felter virker ofte som en enkel avkryssning i systemet, men de påvirker både arbeidsflyt, sporbarhet og hvordan brukere samhandler med data langt mer enn mange tror.
Enten du som sluttbruker lurer på hvorfor et felt er låst eller du er utvikler som vil styre feltadferd i en tilpasning, gir denne guiden en praktisk og teknisk innføring i readonly‑konsepter i Odoo.
Å forstå readonly‑logikken er essensielt for å bygge robuste prosesser, hindre utilsiktede endringer i viktige data og gjøre systemet enklere i bruk for teamet ditt.
Denne gjennomgangen kombinerer forretningsprinsipper og tekniske detaljer slik at du både kan sette opp felt riktig i grensesnittet og implementere dem korrekt i kode.
Hva betyr readonly‑felt i Odoo
Et readonly‑felt i Odoo viser informasjon som brukeren kan lese, men ikke redigere via brukergrensesnittet. Feltet er synlig, men inngang for endring er deaktivert.
I skjemaet vises slike felt ofte som vanlig tekst i stedet for som aktive inndatafelt. Designen kan variere — noen temaer gråner dem ut, andre viser dem som flate tekstlinjer uten input‑ramme.
Readonly‑atferd kan styres på to nivåer i Odoo‑arkitekturen:
- På modellnivå (Python/ORM): feltet er permanent låst i alle sammenhenger
- På visningsnivå (XML): feltet er låst bare i den aktuelle visningen eller under bestemte betingelser
Forskjellen er viktig: et modellnivå‑readonly forhindrer all skriving mot feltet uansett hvor eller hvordan data endres, mens et visningsnivå‑readonly bare er en begrensning i UI‑laget og kan overstyres av serverkode eller andre visninger.
Readonly er ikke en egen felttype — det er et attributt du kan bruke på alle standard Odoo‑felttyper som Char, Integer, Float, Many2one, Date osv. Det er et grunnleggende verktøy for å kontrollere feltadferd i runtime.
Slik fungerer et readonly‑felt
For å få et komplett bilde bør du se både på ORM‑siden (Python) og på visningssiden (XML) i Odoo.
Readonly på ORM‑nivå
I Odoo‑ORM setter du readonly permanent ved å angi readonly=True i feltdefinisjonen i Python. Dette er vanlig for beregnede felt som ikke skal endres av brukeren fordi verdien kommer fra andre data.
Denne typen readonly er en del av felt‑API‑et i Odoo og gjelder globalt — uavhengig av hvilke visninger som viser feltet.
Readonly basert på tilstand
Et typisk mønster er å gjøre felt readonly avhengig av dokumentets tilstand. Standardmoduler låser ofte felter når en ordre eller post går fra utkast til bekreftet for å sikre historikk og rapportering.
Tidligere versjoner brukte attrs‑attributtet i view‑XML for å uttrykke slike regler; nyere Odoo‑versjoner tillater mer konsise inline‑uttrykk direkte på feltelementet.
Begge metoder gir samme resultat: feltet kan redigeres i utkastfasen, men låses når dokumentet går videre i arbeidsflyten — en grunnleggende praksis i Odoo‑konfigurasjon.
Beregnet felt og readonly
Felt som defineres med compute‑metode er som regel readonly som standard, fordi verdien beregnes automatisk fra andre felt.
Ønsker du å lagre beregnede verdier i databasen for ytelse eller søk, bruker du compute sammen med store=True. Lagrede felter er nyttige for filtrering og sortering uten å regne ut verdien hver gang.
Gjør et beregnet felt skrivbart
For at et beregnet felt også skal kunne ta imot manuelle endringer, må du implementere en inverse‑metode. Inversen forteller Odoo hvordan den skal oppdatere underliggende felt når brukeren skriver en verdi; uten inverse forblir feltet readonly.
Når bedrifter bruker readonly‑felt
Readonly‑felt brukes i alle Odoo‑moduler. Her er fem konkrete eksempler fra daglige forretningsprosesser.
1. CRM: Låsning ved vunnet eller tapt
I CRM holdes forventet inntekt og lukkedato redigerbare mens en salgs‑mulighet er aktiv. Når en anledning markeres som vunnet eller tapt, settes disse feltene til readonly for å bevare et korrekt historisk bilde.
Dette forhindrer at noen reviderer tallene i etterkant og gjør salgsrapporter upålitelige.
2. Salg: Beskyttelse av bekreftede ordrelinjer
Når en salgssordre går fra utkast til bekreftet, låses ordrelinjene. Produkt, antall og pris kan ikke endres etter bekreftelse uten en bevisst tilbakestilling til utkast.
Hvis endringer trengs, må ordren settes tilbake til utkast — det gir en tydelig sporbarhet i stedet for utilsiktede justeringer.
3. Lager: Låste utførte mengder
I lagerhåndtering blir mengdene som er registrert ved validering låst for å sikre at lagerverdier stemmer overens med fysiske bevegelser.
Å tillate redigering etter validering kan skape uoverensstemmelser og korrupte beholdningsnivåer på tvers av lokasjoner.
4. Regnskap: Posterte bilagslinjer
I regnskap er det vanlig at bilag som er postert får sine linjer satt til readonly. Dette er både god regnskapsskikk og ofte et krav for samsvar med lover og regler.
Å kunne endre posterte bilag ville svekke påliteligheten i regnskapet og skape juridiske risikoer.
5. Produksjon: Fullførte arbeidsordre
Når en arbeidsordre i produksjon avsluttes, låses registrert tid og produserte mengder for å sikre korrekt kostnadsberegning og ytelsesmåling.
Slik oppretter og tilpasser du et readonly‑felt
To hovedmåter å konfigurere readonly‑felt: uten kode gjennom Odoo Studio, eller teknisk med Python og XML for full kontroll.
Bruke Odoo Studio
Studio lar deg endre readonly‑egenskapen uten å skrive kode. Det er raskt og egnet for administratorer som trenger sikre, reversible endringer.
- Åpne Odoo Studio via blyantikonet i toppmenyen
- Gå til det skjemaet hvor feltet ligger
- Klikk på feltet du vil endre
- I høyre egenskapsfelt slår du på "Readonly"
- Lagre og lukk Studio
Studio støtter også betinget readonly ved hjelp av uttrykk. Du kan for eksempel låse et felt når en status har en bestemt verdi, uten å skrive XML eller Python.
Studio er ofte riktig valg for raske, oppgraderingssikre endringer som konsulenter og systemadministratorer trenger å gjøre i produksjon.
Bruke Python for tekniske tilpasninger
Utviklere setter readonly direkte i Python‑feltdefinisjonen i modellen. Dette er standardpraksis ved modulutvikling og endringer i datamodellen.
readonly=True gjør feltet permanent låst. For mer dynamikk bruker man states‑parametere for å angi i hvilke tilstander feltet skal være skrivbart eller readonly.
Denne metoden er nyttig når du utvider eksisterende modeller i større prosjekter, siden logikken ligger nær dataene og ikke spres over mange visninger.
Bruke XML‑visningsattributter
For visningsnivå‑readonly legger du readonly‑attributtet på feltelementet i view‑XML. Dette er standard ved finjustering av grensesnittet i tekniske tilpasninger.
Fordelen er fleksibilitet: feltet kan oppføre seg forskjellig i ulike visninger uten at du endrer selve feltdefinisjonen i modellen.
I nyere Odoo‑versjoner er uttrykkssyntaksen i XML mer lesbar enn den eldre attrs‑stilen, men begge fungerer avhengig av hvilken Odoo‑versjon du bruker.
Anbefalte fremgangsmåter
Gode readony‑valg handler om nivå, timing og hvorfor feltet skal beskyttes. Følgende retningslinjer fra konsulentpraksis hjelper deg å ta riktige valg.
1. Foretrekk visningsnivå når konteksten varierer
Hvis feltet bare skal låses i visse dokumenttilstander eller visninger, bruk readonly i view‑XML. Det holder modellen fleksibel og lar bakprosesser eller API‑integrasjoner fortsatt endre feltet når nødvendig.
2. Synkroniser readonly‑reglene med dokumentets livssyklus
Lås felt når dokumentet når et stadium der endringer ville skape problemer. Dette gir en forutsigbar brukeropplevelse og støtter en korrekt arbeidsflyt.
3. Test i ulike brukerroller
Readonly kan samhandle med tilgangsregler. Test endringer både som vanlig bruker og som administrator for å sikre at feltet oppfører seg riktig for alle roller.
4. Kombiner readonly og required når det gir mening
Noen felt skal være påkrevd i utkast, men låst senere. Du kan kombinere required og readonly i visningen for å støtte slike scenarier, for eksempel leveringsdatoer eller referansenummer.
5. Dokumenter hvorfor et felt er readonly
I kodebaserte tilpasninger legg alltid igjen kommentarer som forklarer business‑grunnen bak readonly‑valget. Fremtidige utviklere trenger mer enn teknisk kontekst for å vurdere endringer.
6. Bruk Studio for raske, oppgraderingssikre endringer
Studio passer for enkle tilfeller. Reservér Python‑endringer til scenarier der Studio ikke kan håndtere kompleks logikk eller kryss‑feltsbetingelser.
Vanlige fallgruver
Selv rutinerte brukere og utviklere snubler i de samme problemene med readonly‑felt. Kjennskap til disse sparer tid og frustrasjon.
Å forveksle visningsnivå‑readonly med sikkerhet
Readonly i visningen hindrer ikke skriving via XML‑RPC, ORM eller serveractions. Har du et krav om fullstendig skrive‑forbud, må du håndheve det i modellen eller med tilgangsregler, ikke bare i UI.
Å gjøre felt permanent readonly når betinget ville vært riktig
Låser du et felt i modellen for godt, kan det hindre legitime korrigeringsflyter som å sette et dokument tilbake til utkast. Tenk gjennom hele livssyklusen før du velger permanent readonly.
Glemme onchange‑metoder
Et onchange‑skript kan forsøke å sette en verdi på et readonly‑felt og skape uventet oppførsel. Sørg for at onchange‑logikk tar høyde for at enkelte felt kan være låst.
Ulik anvendelse av readonly i forskjellige visninger
Et felt kan være låst i skjema, men fortsatt redigerbart i liste‑ eller kanbanvisning hvis reglene ikke er utført konsekvent. Gå gjennom alle visninger hvor feltet vises.
Bivirkninger ved å arve standardmodeller
Hvis du endrer et standardfelt til readonly via arv i Python, påvirker det alle visninger som bruker feltet — også standard Odoo‑visninger. Forsikre deg om at dette er ønsket adferd.
Oppsummering
Readonly‑felt er et enkelt, men kraftig verktøy for å styre brukerflyt, sikre dataintegritet og håndheve forretningsregler uten å overbelaste opplæring.
Nøkkelen er riktige nivåvalg og at betingelsene reflekterer hvordan teamet faktisk jobber. Et gjennomtenkt readonly‑oppsett gjør Odoo mer pålitelig og lettere å bruke.
Enten du bruker Studio for en kodefri løsning eller skriver feltlogikk i Python og XML, er prinsippet det samme: vis dataen, men beskytt den mot utilsiktede endringer.
Readonly‑felt er kanskje ikke det mest glamorøse temaet i Odoo‑tilpasning, men de har stor innvirkning på kvaliteten i løsningen.
Hos Dasolo hjelper vi selskaper med å implementere, tilpasse og optimalisere Odoo på tvers av moduler og bransjer. Trenger du hjelp til feltkonfigurasjon, arbeidsflytdesign eller datamodellering, står vi klare til å bistå. Kontakt oss og fortell om prosjektet ditt.