Readonly-Felder wirken auf den ersten Blick unspektakulär, entfalten aber im täglichen Betrieb große Wirkung: Sie zeigen Werte an, sperren gleichzeitig die Eingabe und bestimmen so, wie Nutzer mit Daten arbeiten dürfen.
Egal ob Sie als Anwender stutzig werden, weil Eingabefelder ausgegraut sind, oder als Entwickler das Verhalten von Feldern gezielt steuern möchten — diese Übersicht erklärt, warum und wie readonly-Felder sinnvoll eingesetzt werden.
Wer die Mechanik hinter readonly-Feldern versteht, kann Workflows robuster gestalten, Datenfehler verhindern und die Bedienung für das Team klarer und vorhersehbarer machen.
Dieses Tutorial verbindet die betriebliche Praxis mit den technischen Umsetzungsoptionen in Odoo — vom No-Code-Setup bis zur Anpassung im Python-Model und in XML-Views.
Was bedeutet das Feld „readonly“ in Odoo?
Ein readonly-Feld in Odoo zeigt einen Wert an, erlaubt dem Anwender aber keine direkte Bearbeitung über die Oberfläche: sichtbar, aber schreibgeschützt.
In Formularen erscheinen solche Felder oft als reiner Text statt als Eingabefeld; je nach Theme wirken sie leicht ausgegraut oder schlicht nicht interaktiv.
Readonly-Verhalten lässt sich in Odoo auf zwei Ebenen umsetzen:
- Auf Modellebene (Python/ORM): Das Feld ist systemweit schreibgeschützt und lässt sich in keiner Ansicht ändern.
- Auf View-Ebene (XML): Das Feld ist nur in der jeweiligen Ansicht oder unter bestimmten Bedingungen nicht editierbar.
Dieser Unterschied ist entscheidend: Eine ORM-Readonly-Definition sperrt das Feld global, während eine View-Readonly-Regel die Sperre nur für die konkrete Ansicht aufsetzt — andere Views oder serverseitige Prozesse können dann weiterhin schreiben.
Readonly ist kein eigener Feldtyp, sondern ein Attribut, das auf alle üblichen Odoo-Felder wie Char, Integer, Float, Many2one oder Date angewendet werden kann. Es ist ein zentrales Steuerungsmittel im Odoo-Framework.
Wie das readonly-Attribut funktioniert
Um das Verhalten richtig einzuschätzen, lohnt sich ein Blick auf beide Schichten: die Datenmodell-Ebene in Python und die Präsentations-Ebene in XML.
Readonly auf ORM-Ebene
Im ORM können Felder dauerhaft mit readonly=True deklariert werden — das ist üblich für berechnete Felder, deren Wert aus anderen Daten abgeleitet wird. Solche Felder sind aus der UI heraus grundsätzlich nicht änderbar.
Diese Option gehört zur Feld-API in Odoo und wirkt global, unabhängig davon, welche Ansicht geladen ist.
Readonly abhängig von Status
Ein verbreitetes Muster ist, Felder basierend auf dem Dokumentenstatus zu sperren – etwa sobald ein Beleg nicht mehr im Entwurfszustand ist. So verhindern Standardmodule, dass nachträglich kritische Daten verändert werden.
Frühere Odoo-Versionen nutzten dafür XML-attrs mit Bedingungen; neuere Versionen bieten kompaktere Inline-Ausdrücke direkt am Feldelement in der View-Definition.
Beide Wege haben dasselbe Ziel: Bearbeitbar im Entwurf, gesperrt sobald der Workflow einen bestimmten Punkt erreicht hat — eine zentrale Idee für jede Feldkonfiguration.
Berechnete Felder und readonly
Berechnete (compute-)Felder sind per Default readonly, weil ihr Wert aus Logik oder anderen Feldern berechnet wird und nicht manuell gesetzt werden soll.
Setzt man zusätzlich store=True, wird das Ergebnis in der Datenbank persistiert — das verbessert Suche und Sortierung, weil die Werte nicht bei jeder Abfrage neu berechnet werden müssen.
Ein berechnetes Feld beschreibbar machen
Soll ein berechnetes Feld doch manuelle Eingaben akzeptieren, definiert man eine inverse-Methode. Diese beschreibt, wie Odoo mit einem vom Anwender geschriebenen Wert umgehen soll; ohne inverse bleibt das Feld schreibgeschützt.
Praxisnahe Einsatzszenarien
Readonly-Felder finden sich in nahezu jedem Odoo-Modul. Fünf typische betriebliche Beispiele zeigen, wie sie Geschäftsprozesse schützen.
1. CRM: Abschlusswerte einfrieren
In der CRM-Praxis sind Umsatzschätzungen und Abschlussdaten während der Bearbeitung änderbar; nach Statuswechsel zu "gewonnen" oder "verloren" werden diese Felder gesperrt, um die historische Aussage nicht zu verfälschen.
So verhindert man nachträgliches „Korrigieren“, das Verkaufsberichte und Pipeline-Analysen verzerren würde.
2. Verkauf: Bestellpositionen schützen
Sobald eine Bestellung bestätigt ist, sind Positionen (Produkt, Menge, Preis) häufig nicht mehr änderbar — der Kunde hat die Bestätigung erhalten, und nachträgliche Änderungen müssen bewusst angestoßen werden.
Notwendige Anpassungen erfordern meist das Zurücksetzen auf Entwurf oder eine Korrekturprozedur, was die Änderung nachvollziehbar macht.
3. Lager: Gesperrte Mengen nach Validierung
Im Lagerbetrieb werden Mengen nach Bestätigungen gesperrt, damit Lagerbewertung und physische Warenflüsse konsistent bleiben.
Offen editierbare Mengen nach Abschluss würden Bestände über mehrere Standorte hinweg verfälschen.
4. Buchhaltung: Buchungssätze nach dem Buchen
In der Buchhaltung sind gebuchte Belege in der Regel unveränderlich — eine Praxis, die sowohl gesetzlich relevant als auch buchhalterisch korrekt ist.
Nachträgliche Bearbeitungen an gebuchten Buchungen würden die Aussagekraft der Finanzberichte und Compliance gefährden.
5. Fertigung: Abgeschlossene Arbeitsaufträge
Ist ein Arbeitsauftrag als abgeschlossen markiert, werden tatsächliche Laufzeiten und produzierte Mengen gesperrt — wichtig für Kostenrechnung und Leistungsanalyse.
So legen Sie ein readonly-Feld an oder passen es an
Readonly-Felder konfigurieren: zwei Wege
Sie können ohne Code per Odoo Studio arbeiten oder technisch per Python und XML vollständig steuern.
Arbeiten mit Odoo Studio
- Odoo Studio ermöglicht es, Felder und deren Eigenschaften ohne Programmierung zu ändern — ideal für schnelle Anpassungen durch Administratoren oder Berater.
- Starten Sie Studio aus dem Hauptmenü (Bleistift-Icon) und wählen Sie die gewünschte Ansicht aus.
- Klicken Sie das Feld an, das Sie konfigurieren möchten.
- Im rechten Eigenschaftenbereich schalten Sie die Option "Readonly" ein oder aus.
- Änderungen speichern und Studio schließen.
Studio erlaubt auch bedingte readonly-Regeln per Domain-Ausdruck — zum Beispiel ein Feld nur dann sperren, wenn ein Status eine bestimmte Ausprägung hat, ganz ohne Code.
Für viele Anpassungen ist Studio die passende, upgrade-sichere Wahl: Änderungen werden in der Datenbank gehalten und nicht bei Modul-Updates überschrieben.
Technische Anpassung per Python
Entwickler setzen readonly-Attribute direkt in der Felddefinition im Python-Model; das ist der klassische Weg in kundenspezifischen Modulen.
readonly=True macht ein Feld dauerhaft nicht editierbar. Für Zustandsabhängigkeit bieten sich parameter wie states an, um zu definieren, in welchen Dokumentenstadien ein Feld schreibbar oder gesperrt ist.
Diese Methode ist sinnvoll, wenn Feldlogik eng am Datenmodell hängen soll — etwa bei Integrationen oder speziellen Geschäftsregeln.
Readonly in der XML-View steuern
Für View-spezifische Sperren setzt man readonly am Feldelement in der View-XML. Das ist üblich, wenn die gleiche Information in unterschiedlichen Kontexten unterschiedlich behandelt werden soll.
Der Vorteil: dieselbe Felddefinition kann in mehreren Views unterschiedliche Rechte haben, ohne das Datenmodell zu verändern — praktisch, wenn Standardfelder eingeschränkt werden sollen.
In Odoo 17 sind die Inline-Ausdrücke für Conditions übersichtlicher als das ältere attrs-Schema; beide Varianten sind je nach Version weiterhin anwendbar.
Empfehlungen für den sinnvollen Einsatz
Gute Anwendung von readonly-Feldern folgt klaren Regeln: auf der richtigen Ebene einsetzen und die Geschäftsfälle im Blick behalten.
1. Lieber View-Level, wenn der Kontext variiert
Braucht ein Feld nur in bestimmten Views oder Zuständen Sperren, setzen Sie readonly in der View statt im Model. Dadurch bleiben Backend-Prozesse und APIs handlungsfähig, wenn nötig.
2. Readonly an den Lebenszyklus koppeln
Readonly-Regeln sollten dem natürlichen Ablauf eines Dokuments folgen: Felder sperren, wenn weitere Änderungen Schaden anrichten würden — das macht das System für Anwender nachvollziehbar.
3. Tests mit unterschiedlichen Nutzerrollen
Readonly kann mit Zugriffsrechten interagieren. Testen Sie als Standardanwender und als Admin, denn eine Sperre für eine Rolle kann für eine andere noch durchlässig sein.
4. Readonly sinnvoll mit Pflichtfeldern kombinieren
In mehrstufigen Prozessen kann ein Feld im Entwurf Pflicht sein und später readonly — kombinieren Sie required und readonly in der View, wo es sinnvoll ist.
5. Dokumentation der Entscheidungsgründe
Kommentieren Sie in der Codebasis, warum ein Feld readonly ist. Nachfolgende Entwickler müssen die geschäftliche Motivation verstehen, nicht nur die technische Einstellung.
6. Studio für schnelle, sichere Anpassungen nutzen
Wenn Studio die Anforderungen erfüllt, ist es die favorisierte, Upgrade-sichere Option; Python greifen Sie nur an, wenn komplexe Logik oder Integrationen nötig sind.
Häufige Stolperfallen vermeiden
Typische Probleme mit readonly-Feldern und wie man sie vermeidet
View-Readonly nicht mit Sicherheitskontrolle verwechseln
Eine in der View gesperrte Eingabe kann trotzdem über APIs, ORM-Schreibaufrufe oder Serveraktionen verändert werden. Wenn ein Feld wirklich unveränderlich sein muss, sichern Sie das auf der ORM-Ebene oder per Access-Control-Rule ab.
Felder dauerhaft sperren, obwohl gelegentliche Schreibrechte nötig sind
Permanent gesetzte readonly-Flags blockieren auch legitime Korrekturabläufe wie das Zurücksetzen auf Entwurf. Prüfen Sie Lebenszyklen genau, bevor Sie global sperren.
Onchange-Methoden nicht berücksichtigen
Wenn readonly-Felder in onchange-Methoden verändert werden, kann es zu unerwartetem Verhalten kommen — etwa sichtbare, aber nicht persistente Änderungen oder Fehler. Passen Sie onchange-Logik an die Sperrregeln an.
Readonly nicht in allen Views konsistent anwenden
Ein Feld mag im Formular gesperrt sein, aber in Listen- oder Kanban-Ansichten noch editiert werden, wenn dort die Restriktion fehlt. Prüfen Sie alle Views, in denen das Feld auftaucht.
Seiteneffekte beim Erben von Standardmodellen
Wenn Sie ein Standardfeld per Inheritance mit readonly=True überschreiben, wirkt sich das auf alle Anzeigen dieses Feldes aus — auch auf Standardansichten. Seien Sie sicher, dass das beabsichtigt ist.
Zusammenfassung
Readonly-Felder sind ein einfaches, aber wirkungsvolles Mittel, um Nutzer zu führen, Daten zu schützen und Geschäftsregeln ohne endlose Schulungen durchzusetzen.
Entscheidend ist die richtige Ebene und die Übereinstimmung mit Ihren Geschäftsprozessen: View- oder Model-Level, bedingte Sperren und klare Lifecycle-Logik machen den Unterschied.
Ob via Odoo Studio oder über Python und XML eingebaut — das Prinzip bleibt gleich: Werte darstellen, ungewollte Änderungen verhindern.
Sie sind vielleicht unscheinbar, werden selten in Präsentationen gefeatured, aber haben großen Einfluss auf die Datenqualität.
Bei Dasolo unterstützen wir Unternehmen beim Implementieren, Anpassen und Optimieren von Odoo über alle Module hinweg. Wenn Sie Hilfe bei Feldern, Workflows oder Modell-Design brauchen, begleiten wir Sie gern. Nehmen Sie Kontakt auf und erzählen Sie uns von Ihrem Vorhaben.