Readonly-velden lijken op het eerste gezicht eenvoudig: ze tonen informatie maar laten geen bewerking toe. In werkelijkheid sturen ze vaak kritieke beslissingen in processen en beschermen ze de betrouwbaarheid van je gegevens.
Of je nu als eindgebruiker merkt dat een veld grijs is en wil weten waarom, of als ontwikkelaar controle wil inbouwen in een maatwerkmodule — deze gids legt helder uit wat readonly in Odoo betekent en wanneer je het best inzet.
Inzicht in readonly-gedrag helpt bij het opzetten van robuuste workflows, het voorkomen van foutieve aanpassingen en het soepel laten verlopen van dagelijkse taken voor je team.
Deze handleiding behandelt zowel de zakelijke kant als de technische implementatie van readonly-velden, zodat je — ongeacht of je configureert via Studio of codeert in Python/XML — de juiste keuzes kunt maken.
Wat betekent een readonly-veld in Odoo?
Een readonly-veld toont een waarde in Odoo maar blokkeert directe invoer via de gebruikersinterface. Gebruikers zien de informatie, maar kunnen ze niet zomaar aanpassen.
In formulierweergaven worden readonly-velden meestal als tekst weergegeven in plaats van als invoervelden. Visueel vallen ze vaak minder op dan bewerkbare velden — bijvoorbeeld vlakker of iets gedempt.
In Odoo kun je readonly-gedrag op twee niveaus toepassen:
- Op het modelniveau (Python/ORM): het veld is overal en altijd readonly
- Op het weergaveniveau (XML): het veld is readonly in een specifieke view of onder bepaalde voorwaarden
Dat onderscheid is cruciaal: een veld dat in de ORM readonly is, kan nergens via de UI worden aangepast. Een view-level readonly beperkt alleen de bewerking in die specifieke context; andere views of serverprocessen kunnen het veld nog steeds wijzigen.
Readonly is geen apart veldtype, maar een attribuut dat je op alle gangbare Odoo-veldtypes toepast: Char, Integer, Float, Many2one, Date, enzovoort. Het is een kernmechanisme om runtime-gedrag te sturen.
Hoe een readonly-veld in de praktijk werkt
Om het gedrag van readonly-velden te begrijpen, kijk je zowel naar het ORM (Python) als naar de view-laag (XML).
Readonly op ORM-niveau
In de Python-modellen geef je een veld permanent readonly door in de velddefinitie readonly=True te zetten. Dat zie je vaak bij berekende (computed) velden: hun waarde komt uit berekeningen, dus gebruikers mogen ze niet rechtstreeks overschrijven.
Dit is onderdeel van de officiële Odoo-fields API en geldt globaal, ongeacht welke view wordt gebruikt.
Readonly afhankelijk van status
Een veelgebruikte aanpak is velden vergrendelen op basis van de status van een document. Standaardmodules zoals Sales of Accounting vergrendelen gegevens zodra een document niet langer in concept staat.
In oudere Odoo-versies deed je dit via attrs in de view-XML; nieuwere releases ondersteunen kortere inline-expressies rechtstreeks op het veld in de XML.
Beide technieken leiden tot hetzelfde resultaat: bewerkbaar in concept, vergrendeld na doorgang in het proces. Het is een fundamenteel patroon bij het instellen van formulieren en workflows.
Computed-velden en readonly
Computed-velden zijn standaard readonly omdat hun waarde automatisch wordt berekend uit andere velden. Odoo gaat ervan uit dat handmatige aanpassing niet gewenst is.
Wil je die berekende waarde toch bewaren in de database (bv. voor zoekperformance), dan zet je compute samen met store=True. Zo kun je sneller filteren en sorteren zonder steeds opnieuw te rekenen.
Een computed-veld schrijfbaar maken
Als je een computed-veld wil toestaan om manueel ingevuld te worden, definieer je een inverse-functie. Die inverse vertelt Odoo hoe het invoer moet omzetten naar de onderliggende bronnen. Zonder inverse blijft het veld readonly.
Wanneer bedrijven readonly-velden gebruiken
Readonly-velden komen in elk Odoo-module voor. Hieronder vijf concrete toepassingen uit de praktijk.
1. CRM: resultaten van afgesloten opportuniteiten vergrendelen
In CRM blijven geschatte omzet en sluitingsdatum wijzigbaar zolang een opportuniteit in behandeling is. Na markering als Gewonnen of Verloren worden die velden vergrendeld om een betrouwbare historiek te bewaren.
Zo voorkom je dat cijfers achteraf worden aangepast en rapporten vertekend raken.
2. Sales: bevestigde orderregels beschermen
Zodra een verkooporder bevestigd is, mogen orderregels — product, hoeveelheid en prijs — niet meer wijzigen. De klant ontving immers al een bevestiging.
Als er echt een wijziging nodig is, zet je de order terug naar concept zodat er een bewuste correctie met audittrail ontstaat.
3. Voorraad: gevalideerde verplaatsingen vergrendelen
Bij magazijnprocessen worden zodra leveringen of ontvangsten gevalideerd de verwerkte hoeveelheden vastgezet. Dat beschermt voorraadwaardering en zorgt dat registraties overeenkomen met fysieke bewegingen.
Bewerkbare hoeveelheden na validatie kunnen anders stilletjes stockniveaus beschadigen.
4. Boekhouding: geboekte journaalposten
In de boekhouding worden journaalposten na het boeken niet meer aangepast. Dit is zowel een wettelijke noodzaak in veel landen als een basisprincipe van betrouwbare financiële administratie.
Mogelijkheid tot aanpassen na boeken ondermijnt cijfers en creëert risico’s voor naleving.
5. Productie: afgeronde werkorders
In productie worden duur en output van afgewerkte werkorders vergrendeld wanneer ze op 'afgewerkt' staan. Daardoor blijft de productieregistratie intact voor kostprijzen en prestatieanalyse.
Hoe je zelf een readonly-veld maakt of aanpast
Er zijn twee routes om readonly-velden in te voeren: no-code via Odoo Studio of technisch via Python en XML.
Werken met Odoo Studio
Odoo Studio maakt het eenvoudig om readonly-gedrag in te stellen zonder te programmeren. Zo configureer je snel een veld als readonly:
- Open Odoo Studio (potlood-icoon)
- Ga naar de formulierweergave waar je het veld wil aanpassen
- Selecteer het veld
- Schakel in het rechterpaneel de optie 'Readonly' in
- Sla op en sluit Studio
Studio laat je ook conditionele readonly-regels instellen met eenvoudige expressies — bijvoorbeeld een veld alleen vergrendelen wanneer een statuswaarde gelijk is aan X — zonder code.
Voor consultants en beheerders is Studio ideaal voor snelle, veilige aanpassingen. Instellingen via Studio blijven bewaard en worden niet weggegooid bij module-updates.
Technische aanpassingen in Python
Ontwikkelaars definiëren readonly rechtstreeks op het veld in het Python-model. Dit is de standaardmethode binnen Odoo-ontwikkeling.
Je gebruikt readonly=True voor permanente vergrendeling, of het states-attribuut om in welke statussen het veld wél of niet bewerkbaar is te specificeren.
Dit is handig bij het uitbreiden van bestaande modellen: de logica blijft dicht bij het datamodel en voorkomt versnipperde regels verspreid over veel views.
Readonly in view-XML
Voor view-specifieke vergrendeling voeg je readonly toe op het betreffende veld in de XML-view. Dat is onderdeel van de gebruikelijke ontwikkelworkflow.
Het voordeel van view-level readonly is flexibiliteit: hetzelfde veld kan in ene view bewerkbaar zijn en in een andere vergrendeld, zonder de Python-definitie aan te passen.
In nieuwere Odoo-versies is de inline-syntaxis voor readonly-condities compacter en leesbaarder dan de oude attrs aanpak; beide blijven bruikbaar afhankelijk van je versie.
Aanbevolen werkwijzen
Goed gebruik van readonly draait om niveaukeuze en zakelijk doel. Hieronder staan belangrijkste richtlijnen vanuit adviespraktijk.
1. Gebruik view-level readonly als de context varieert
Als een veld alleen in bepaalde statussen of views vergrendeld moet zijn, doe dat dan op view-niveau. Zo blijft het datamodel flexibel en kunnen backendprocessen nog altijd schrijven wanneer dat nodig is.
2. Stem readonly af op de levenscyclus van documenten
Lockregels moeten aansluiten bij het natuurlijke proces van het document. Velden vergrendelen op het juiste moment voorkomt verrassingen en maakt de workflow voorspelbaar voor gebruikers.
3. Test vanuit verschillende gebruikersprofielen
Readonly kan onverwacht interactie hebben met toegangsrechten. Test altijd als gewone gebruiker en als administrator om zeker te zijn dat het gedrag voor beide rollen correct is.
4. Combineer readonly met required wanneer dat logisch is
Soms is een veld verplicht in draft maar readonly later. Je kunt beide attributen combineren in de view om dat patroon duidelijk af te dwingen.
5. Leg je readonly-logica vast in commentaar
Bij maatwerk: documenteer waarom een veld vergrendeld is. Latere ontwikkelaars moeten de zakelijke reden kunnen zien, niet alleen de technische regel.
6. Kies Studio voor snelle, upgrade-veilige aanpassingen
Studio is de beste optie voor eenvoudige gevallen. Reserveer Python voor complexe voorwaarden, cross-field logica of integratie met compute/inverse methodes.
Veelvoorkomende fouten en valkuilen
Ook ervaren teams maken fouten met readonly. Hieronder de valkuilen waar je alert op moet zijn.
Verwarren van view-readonly met echte beveiliging
Een readonly in de view blokkeert alleen de UI. API-aanroepen, ORM-writes of serveracties kunnen het veld nog steeds aanpassen. Als je volledige bescherming wil, zet de beperking op ORM- of toegangsregel-niveau.
Veld permanent readonly maken terwijl het conditioneel genoeg zou zijn
Het is verleidelijk een veld volledig te vergrendelen, maar soms moeten gebruikers het in uitzonderlijke gevallen kunnen wijzigen (bv. bij reset naar concept). Een permanente readonly kan legitieme correcties blokkeren.
Onthouden van onchange-methodes
Een onchange kan nog steeds proberen een readonly-veld te vullen, wat tot rare wisselende waardes of fouten leidt. Zorg dat je onchange-logica rekening houdt met vergrendelde velden.
Niet consequent toepassen in alle views
Een veld dat in het formulier readonly staat, kan in de lijst- of kanban-view nog bewerkbaar zijn als je die niet ook aanpast. Controleer alle views waar het veld voorkomt.
Bij overerving onverwachte bijwerkingen
Wanneer je een standaardmodel overerft en readonly=True toevoegt aan een bestaand veld, gelden die wijzigingen voor álle weergaven. Doe dit alleen als je zeker weet dat dat geen standaardfunctionaliteit kapotmaakt.
Samenvatting
Readonly-velden zijn een belangrijk instrument om gebruikers door processen te leiden, gegevens te beschermen en bedrijfsregels te handhaven zonder uitsluitend te vertrouwen op training.
Het draait erom op het juiste moment en het juiste niveau te vergrendelen. Een goed doordacht datamodel gebruikt readonly-velden doelgericht tijdens cruciale stappen in de levenscyclus van een document.
Of je nu Studio gebruikt voor een no-code aanpak of Python en XML inzet voor maatwerk, de gedachte achter readonly blijft gelijk: tonen wat nodig is, en tegelijk ongewenste wijzigingen vermijden.
Ze worden misschien niet vaak besproken, maar readonly-velden hebben een stille, grote impact op betrouwbaarheid en gebruiksgemak.
Bij Dasolo begeleiden we bedrijven bij implementatie, maatwerk en optimalisatie van Odoo binnen verschillende sectoren. Heb je hulp nodig bij veldconfiguratie, workflowontwerp of het verbeteren van je datamodel? Wij kunnen ondersteunen. Neem contact op en vertel ons over je project.