Readonly-felter virker som en lille, enkel detalje i Odoo, men de former faktisk hvordan data flyder i hele systemet — fra brugernes daglige arbejde til regnskabets pålidelighed.
Uanset om du sidder med et felt, der er gråt og låst, eller du bygger en løsning hvor visse værdier kun må ændres i bestemte situationer, giver denne guide dig de praktiske forklaringer og valg, du skal træffe.
Når du forstår readonly-logikken, kan du lave arbejdsgange der er både robuste og intuitive: brugere får færre fejl, og virksomhedens data forbliver konsistente og pålidelige.
Denne artikel dækker både det forretningsmæssige og det tekniske: fra konfiguration uden kode til udviklerens værktøjskasse, så du ved hvornår og hvordan readonly bør anvendes.
Hvad er et readonly-felt i Odoo
Et readonly-felt i Odoo viser en værdi, men brugeren kan ikke ændre den direkte via brugerfladen — det er læsbart, men input er deaktiveret.
I formularvisningen fremstår sådanne felter oftest som almindelig tekst fremfor en aktiv indtastningsboks; de kan visuelt virke dæmpede eller flade sammenlignet med redigerbare felter.
Readonly-indsatsen i Odoo kan placeres på to niveauer i systemet:
- På felt-niveau (Python/ORM): feltet er konstant readonly i alle visninger og situationer
- På visnings-niveau (XML): feltet er readonly i en konkret visning eller under bestemte betingelser
Det er vigtigt at skelne: en feltdefinition med readonly i ORM’en forhindrer enhver skrivning via UI og API, mens readonly i en visning kun begrænser brugerens interaktion i netop den visning.
Readonly er ikke en ny felttype — det er en egenskab du kan sætte på alle Odoo-felttyper som Char, Integer, Many2one, Date osv., og bruges til at styre feltadfærd ved runtime.
Sådan virker readonly-feltet
For at forstå konsekvenserne af readonly bør du kigge på både model-laget (Python/ORM) og visningslaget (XML), for de spiller sammen men har forskellige domæner.
Readonly i ORM’en
I Odoo kan et felt deklareres permanent readonly i Python-modellen — det bruges ofte til beregnede felter, hvor værdien kommer fra en compute-metode og ikke skal indtastes manuelt. Dette sættes med readonly=True i feltdefinitionen.
Denne form for readonly er del af Odoo’s felt-API og gælder globalt, uanset hvilken formular eller visning brugeren ser.
State-baseret readonly
Et almindeligt mønster er at låse felter afhængigt af dokumentets tilstand. Når en ordre eller post bevæger sig videre fra udkast, låses visse felter for at fastholde et korrekt historisk billede.
Tidligere versioner af Odoo håndterede det ofte via attrs i view-XML; nyere versioner understøtter mere kompakte inline-betingelser direkte på feltet.
Begge metoder har samme mål: feltet kan redigeres i udkastfasen, men låses når dokumentet skifter status — et grundlæggende mønster i Odoo-konfigurationer.
Beregnefelter og readonly
Felt med compute-metode er som udgangspunkt readonly, fordi systemet antager at værdien bliver genereret automatisk fra andre felter.
Ønsker du samtidig at gemme beregnede værdier i databasen, bruger du compute sammen med store=True, hvilket gør dem søgbare og hurtigere at sortere på i store datasæt.
Gør et beregnet felt skrivbart
Hvis du vil tillade manuel indtastning i et beregnet felt, skal du implementere en inverse-metode. Den fortæller Odoo, hvordan det skal håndtere brugerens ændringer — uden inverse forbliver feltet readonly.
Reelle forretningsscenarier
Readonly-felter findes i alle standardmoduler. Her er fem konkrete eksempler fra daglig drift, hvor låsning af felter beskytter processer og rapportering.
1. CRM: Låsning af vind/ tabt-opportunitydata
I CRM ændres estimater og lukkedato mens en lead er under behandling. Når en mulighed markeres som Vundet eller Tabt, låses disse felter for at bevare et troværdigt historisk billede.
Det forhindrer bagudrettede ændringer, som ellers ville skævvride salgsrapporter og pipeline-analyser.
2. Salg: Beskytte bekræftede ordrelinjer
Når en salgsordre bekræftes, bliver ordrelinjerne ulæselige for redigering — produkt, antal og pris kan ikke ændres efter kunden har fået bekræftelsen.
Rigtige ændringer kræver en eksplicit tilbageførsel til udkast, hvilket efterlader en revision og gør korrektionen bevidst i stedet for utilsigtet.
3. Lager: Låste validerede beholdningsmængder
Når en leverance eller modtagelse er valideret, låses de registrerede mængder. Det sikrer, at lageropgørelsen stemmer overens med den fysiske varestrøm og værdifastsættelse.
Hvis mængder kan rettes efter validering, kan lagerbalancen hurtigt blive ukorrekt flere steder i systemet.
4. Regnskab: Bogførte journalpostlinjer
Efter en journalpost er bogført, bliver dens linjer readonly — både af juridiske grunde og for at bevare integriteten i dobbelt bogholderi.
At tillade redigering efter bogføring vil svække regnskabets pålidelighed og kunne skabe alvorlige compliance-problemer.
5. Produktion: Afsluttede arbejdsordrer
Når en arbejdsordre er markeret som færdig, låses varighed og producerede mængder. Dermed bevarer du korrekte produktionsdata til kostberegning og performanceanalyse.
Opret eller tilpas et readonly-felt
Der er primært to måder at sætte readonly op i Odoo: den no-code vej med Odoo Studio, eller den tekniske vej med Python og XML til fuld kontrol.
Brug af Odoo Studio
Odoo Studio er velegnet hvis du vil ændre readonly-adfærd uden at røre kode. Det er hurtigt for konsulenter og systemansvarlige.
- Åbn Odoo Studio via blyantikonet i menuen
- Gå til formularen hvor feltet ligger
- Klik på feltet du vil ændre
- I egenskabspanelet til højre kan du slå Readonly til eller fra
- Gem og luk Studio
Studio lader dig også definere betinget readonly via udtryk: fx lås kun feltet når en status har en bestemt værdi — ingen kode nødvendig.
For hurtige, sikre ændringer er Studio ofte det rigtige valg, fordi ændringerne ligger i databasen og ikke bliver overskrevet ved opdateringer af moduler.
Teknisk tilpasning med Python
Som udvikler sætter du readonly direkte i feltdefinitionen i Python-modellen — det er standardmønsteret i Odoo-udvikling.
Du kan bruge readonly=True for en statisk lås, eller states-parameteren for at definere hvornår feltet er læsbart versus skrivbart afhængig af dokumentets status.
Denne metode er god, når du tilføjer specialfelter til eksisterende modeller, fordi forretningslogikken ligger tæt på data-modellen i stedet for spredt over mange visninger.
Visningsniveau via XML-attributter
Vil du begrænse redigering kun i en given visning, sætter du readonly på feltet i view-XML. Det er standardarbejdsgangen ved visningsændringer.
Fordelen er fleksibilitet: et felt kan være skrivbart i en rapport og låst i en formular uden at ændre feltdefinitionen i Python, hvilket er praktisk når du vil tilpasse UI uden at påvirke backend-logikken.
I nyere Odoo-versioner er syntax til betinget readonly mere læsbar end de ældre attrs-diktionærer, men begge metoder er valide afhængig af din Odoo-version.
Gode fremgangsmåder
At bruge readonly fornuftigt handler om at placere begrænsningen korrekt og afklare hvorfor den eksisterer. Nedenfor er de vigtigste retningslinjer en Odoo-konsulent vil anbefale.
1. Foretræk visningsniveau når konteksten varierer
Hvis et felt kun skal være låst i visse dokumenttilstande eller i specifikke skærmbilleder, sæt readonly i view-XML fremfor i modellen — det bevarer fleksibiliteten for backendprocesser og API’er.
2. Sørg for at readonly følger dokumentets livscyklus
Lås felter når dokumentets tilstand gør yderligere ændringer risikable. Det giver brugerne et forudsigeligt workflow og minimerer fejl i processen.
3. Test på tværs af brugerroller
Readonly kan opføre sig forskelligt afhængigt af adgangsrettigheder. Test altid som almindelig bruger og som admin for at sikre at reglerne gælder for de rette grupper.
4. Kombinér readonly med required hvor det giver mening
I workflows med flere stadier kan et felt være påkrævet i udkast, men readonly senere. Brug begge attributter sammen i view-XML for at håndhæve dette mønster konsistent.
5. Dokumentér din readonly-logik
Skriv kommentarer i koden der forklarer hvorfor et felt er låst. Fremtidige udviklere har brug for forretningsmæssig kontekst, ikke kun tekniske flags.
6. Brug Studio til hurtige og opgraderingssikre ændringer
Odoo Studio er ofte tilstrækkeligt for simple tilfælde; gem Python-tilpasninger til situationer hvor Studio ikke kan dække komplekse krydsfelt-regler eller særlige inverse-metoder.
Almindelige faldgruber
Selv erfarne brugere snubler i nogle typiske problemer med readonly. Her er dem du bør kende til, så de ikke overrasker dig.
Forveksling af visnings-readonly med sikkerhedspolicy
At gøre et felt readonly i en visning stopper ikke opdateringer gennem API’er, server-kald eller ORM-skrivninger. Visnings-readonly er blot en UI-begrænsning — ønsker du fuldstændig beskyttelse, håndhæv den i modellen eller via adgangskontrolregler.
Gøre felter permanent låst når betinget lås ville være bedre
Det kan være fristende at markere et felt permanent readonly for at beskytte det. Husk dog at det blokerer alle korrektioner, fx tilbagerulninger til udkast. Overvej hele livscyklussen før du vælger permanent låsning.
Glemme onchange-metoder
En onchange kan stadig forsøge at skrive til et readonly-felt, hvilket skaber forvirrende adfærd (feltet ser ud til at ændre sig, så reverteres eller giver fejl). Sørg for at onchange-logikken tager readonly-felter i betragtning.
Manglede readonly på tværs af alle visninger
Et felt kan være låst i formularvisningen, men stadig være redigerbart i liste- eller kanban-visningen hvis du ikke duplikerer begrænsningen. Tjek alle visninger hvor feltet optræder.
Bivirkninger ved at arve standardmodeller
Hvis du arver en standardmodel og sætter readonly=True på et eksisterende felt, påvirker det alle visninger, også standard-Odoo. Vær sikker på at det ikke bryder andres funktionalitet.
Afsluttende tanker
Readonly-felter er et centralt værktøj i Odoo til at styre arbejdsgange, sikre datakvalitet og håndhæve forretningsregler uden at overlade alt til brugertræning.
Det afgørende er at afgøre om readonly skal sættes i visninger eller i modellen, og at betingelserne matcher den måde jeres team arbejder på i praksis.
Uanset om du bruger Studio til no-code eller Python/XML til tekniske tilpasninger, er formålet det samme: vis data, men beskyt den mod utilsigtede ændringer.
Readonly-felter er måske ikke det mest flashy emne i Odoo, men de har stor effekt på driftens stabilitet og datatil troværdighed.
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo på tværs af brancher. Vi rådgiver i feltdesign, arbejdsgange og datamodeller, så I får både brugervenlighed og kontrol. Kontakt os og fortæl om dit projekt.