Einführung
Jedes Mal, wenn in Odoo eine Lead-Priorität gesetzt, eine Zahlungsart ausgewählt oder ein Produkt als aktiv/archiviert markiert wird, steckt meist ein Selection-Feld dahinter. Es ist ein minimalistisches, aber mächtiges Feldformat: kompakt, leicht zu validieren und zentral für saubere Datenmodelle.
Im Gegensatz zu Freitextfeldern begrenzt ein Selection-Feld die Eingabe auf vorab definierte Optionen. Dieses Festlegen von Wahlmöglichkeiten sorgt für konsistente Werte, erleichtert Filter und Auswertungen und verhindert Tippfehler oder Varianten, die später Berichte und Automatisierungen korrumpieren können.
Dieser Leitfaden erklärt, was ein Selection-Feld intern speichert, wie es im UI dargestellt wird und wie Sie es über Odoo Studio, Python-Module oder die API anlegen und erweitern. Dazu gibt es konkrete Anwendungsfälle und eine Liste typischer Fehler, die Sie vermeiden sollten.
Was ist das Selection-Feld in Odoo
Im Odoo-ORM wird im Selection-Feld jeweils ein String gespeichert, der aus einer festen Auswahl stammt. Jede Option besteht aus einem technischen Schlüssel (der in der Datenbank liegt) und einem sichtbaren Label für den Anwender.
Ein praktisches Beispiel ist ein Prioritätsfeld, das aus mehreren vorgegebenen Werten besteht.
priority = fields.Selection([
('0', 'Normal'),
('1', 'Low'),
('2', 'High'),
('3', 'Very High'),
], string='Priority', default='0')
In diesem Beispiel sind '0'–'3' die in der DB gespeicherten Schlüssel; die Begriffe Normal, Low usw. sind nur die Anzeigenamen. Diese Trennung ist wichtig: Labels können geändert werden, ohne bestehende Datensätze zu zerstören — Schlüssel dagegen sind die stabilen Referenzen.
Im Interface zeigt sich ein Selection-Feld typischerweise als Dropdown in Formularen; in Listen sieht man das menschenlesbare Label. Mit dem badge-Widget lassen sich Optionen als farbige Markierungen darstellen, was besonders in dichten Listen oder Kanban-Ansichten die Übersicht verbessert.
In Odoo Studio heißt dieses Feld ebenfalls Selection. Felder, die über Studio angelegt werden, bekommen eine x_studio_-Präfix; wer per Code oder API arbeitet, vergibt technische Namen selbst.
Wie das Feld funktioniert
Auf Datenbankebene landet ein Selection-Feld als VARCHAR-Spalte in PostgreSQL. Wichtig: gespeichert wird ausschließlich der Schlüssel, nie das Label. Das ist relevant, wenn Sie Domains, Server-Aktionen oder SQL-Abfragen schreiben — arbeiten Sie mit dem Key, nicht mit dem sichtbaren Text.
Beispiel: Für alle Leads mit hoher Priorität lautet die Domain [('priority', '=', '2')], nicht [('priority', '=', 'High')].
Wichtige Feld-Eigenschaften
Das sind die zentralen Attribute, die Sie bei Selection-Feldern kennen sollten:
- selection: Die Liste der
(key, label)-Tupel mit den verfügbaren Optionen. Alternativ kann hier ein Methodenname (als String) stehen, der die Liste dynamisch zurückgibt. - default: Der Schlüssel, der verwendet wird, wenn noch kein Wert gesetzt ist. Wird kein Default definiert, bleibt das Feld leer.
- required: Erzwingt, dass der Anwender eine Auswahl trifft, bevor gespeichert werden kann. In Kombination mit einem Default ist das gängige Muster für Statusfelder.
- selection_add: Erlaubt es, beim Erweitern eines Moduls zusätzliche Optionen zu einem bestehenden Selection-Feld hinzuzufügen, ohne die ganze Definition neu zu schreiben — die richtige Methode zum Austauschen von Optionen in nativen Feldern.
- ondelete: Legt zusammen mit
selection_addfest, was mit Datensätzen passieren soll, deren Option entfernt wird, wenn das erweiternde Modul deinstalliert wird.
Statische vs. dynamische Auswahllisten
Standardmäßig definieren Sie die Optionen statisch im Feld. Alternativ können Sie einen Methodennamen übergeben: Odoo ruft die Methode zur Laufzeit auf und baut die Auswahl dynamisch auf — z.B. abhängig vom aktuellen Benutzer, der Firma oder sonstigen Kontextinformationen.
contract_type = fields.Selection(
selection='_get_contract_types',
string='Contract Type'
)
def _get_contract_types(self):
if self.env.user.has_group('hr.group_hr_manager'):
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term'), ('interim', 'Interim')]
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term')]
Darstellung in Views
Im Formular ist das Selection-Feld ein Dropdown. Mit widget="badge" wird es als farbige Etikette gerendert (ideal für Status im Kanban oder in Listen). widget="radio" zeigt die Optionen als Inline-Radio-Buttons — sinnvoll bei wenigen, gleich sichtbaren Auswahlmöglichkeiten.
Verhalten im ORM
Lesen und Schreiben ist einfach: Sie setzen den Schlüsselwert, das Framework zeigt automatisch das zugehörige Label. Beim Abruf über die XML-RPC-API liefert fields_get die vollständige selection-Liste mit [key, label]-Paaren, die externe Tools zur Anzeige nutzen können.
Praxisbeispiele aus dem Geschäftsalltag
Selection-Felder finden sich in fast jedem Odoo-Modul. Im Folgenden fünf typische Anwendungsfälle, die zeigen, wie zentral dieses Feldformat ist.
CRM: Lead-Priorität und Pipeline-Typen
Die Priorität bei Leads ist ein Standard-Selection-Feld (z. B. Normal, Niedrig, Hoch, Sehr hoch). Sales-Teams filtern damit ihre Aufmerksamkeit, Kanban-Farbcodierung und automatisierte Aktionen greifen darauf zurück — z. B. um Nachverfolgungsaufgaben bei Eskalationen zu erzeugen. Ein sauber verteilter Prioritätenbestand ist oft eine der ersten Datenqualitätsmaßnahmen nach der Einführung.
Vertrieb: Zahlungsbedingungen und Rechnungslogik
Das Feld invoice_policy bei Produkten entscheidet, ob die Fakturierung nach bestellten oder gelieferten Mengen erfolgt — ein einziger Schlüssel steuert damit den gesamten Billing-Flow eines Produkts. Auch bei Abonnements differenziert ein Selection-Feld Prepaid vs. Postpaid. Solche Felder haben direkte Folgen für Finanzprozesse und Buchungen.
Lager: Zustände von Produkten und Losen
In Produktion und Qualitätssicherung werden Statusfelder als Selection eingesetzt — z. B. für Lot- oder Seriennummern-Zustände oder Reparaturaufträge (draft → confirmed → under repair → ready → done). Zustandswechsel können E-Mails, Lagerbewegungen oder Buchungseinträge auslösen. Das Selection-Feld bildet hier den zentralen Steuerpunkt des Workflows.
Buchhaltung: Zahlungsarten und Journaltypen
Das Journal-Typ-Feld unterscheidet Verkaufs-, Einkaufs-, Kassen- und Bankjournale. Odoo nutzt diesen Wert, um Buchungslogik anzuwenden, verfügbare Konten zu filtern und bestimmte Aktionen nur für passende Journale zu erlauben. Hier steuert das Selection-Feld Geschäftsregeln, nicht nur die Beschriftung eines Datensatzes.
HR: Beschäftigungsart und Vertragsstatus
Im HR-Bereich bilden Selection-Felder Vertragsarten und -zustände ab (z. B. neu → offen → abgelaufen/gekündigt). Automatisierungen können Personalverantwortliche rechtzeitig informieren, Onboarding-Tasks anstoßen oder Gehaltsregeln anpassen — alles ausgelöst durch den im Selection-Feld gespeicherten Zustand.
Selection-Feld anlegen oder anpassen
Drei Wege führen zur Anlage eines Selection-Feldes — je nach Bedarf nach No-Code, Versionierung und Automatisierung.
Per Odoo Studio (No-Code)
Odoo Studio ist das Low-Code-Tool, um Felder ohne Python zu erstellen. So legen Sie ein Selection-Feld in Studio an:
- Studio aus dem Hauptmenü öffnen.
- Zum gewünschten Formular navigieren.
- Ein Selection-Feld aus der Seitenleiste auf das Formular ziehen.
- Im Eigenschaftenfenster die Optionen als Labels eintragen.
- Optional Default setzen und als Pflichtfeld markieren.
- Studio speichern und verlassen.
Studio generiert Schlüssel automatisch und versieht den Feldnamen mit x_studio_. Das ist der schnellste Weg, um während Workshops oder Anforderungsanalysen Felder hinzuzufügen.
Per Python in einem Custom Module
Für Entwickler und für Änderungen, die versioniert und reproduzierbar sein sollen, definieren Sie Selection-Felder im Python-Modell. Das ist die empfohlene Methode für produktive Anpassungen:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_delivery_slot = fields.Selection([
('morning', 'Morning (8h - 12h)'),
('afternoon', 'Afternoon (13h - 17h)'),
('evening', 'Evening (18h - 20h)'),
], string='Delivery Slot', default='morning')
Das Feld wird anschließend in der View-XML eingebunden; Odoo legt beim Installieren/Upgraden das Datenbankfeld an.
Zum Erweitern eines nativen Feldes fügen Sie neue Optionen mit selection_add hinzu, statt die gesamte Definition zu überschreiben:
class SaleOrder(models.Model):
_inherit = 'sale.order'
state = fields.Selection(
selection_add=[('custom_approval', 'Pending Approval')],
ondelete={'custom_approval': 'set default'}
)
Per XML-RPC API
Wenn Sie Odoo-Felder programmgesteuert verwalten wollen — etwa in Deploymentskripten oder Remote-Konfigurationen — lassen sich Selection-Felder auch über die XML-RPC API anlegen:
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_contract_category',
'field_description': 'Contract Category',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('standard', 'Standard'), ('premium', 'Premium'), ('custom', 'Custom')]",
'state': 'manual',
}]
)
Wichtig: Bei API-Erstellung wird die selection-Liste als String übergeben. state: 'manual' kennzeichnet Felder, die nicht aus Modulen stammen — passend für Studio- oder API-erstellte Felder und für automatisierte Konfigurationen.
Best Practices
1. Verwenden Sie aussagekräftige, stabile Schlüssel
Der Schlüssel ist die einzige dauerhafte Referenz in DB und Code. Wählen Sie kurze, sprechende, konsistente Keys ('draft', 'confirmed', 'cancelled') und vermeiden Sie Zahlen als Schlüssel, sofern die Reihenfolge keine semantische Bedeutung hat — Lesbarkeit gewinnt langfristig an Gewicht.
2. Halten Sie die Liste kurz und vollständig
Mehr als acht bis zehn Optionen deuten oft darauf hin, dass ein Selection-Feld überfrachtet ist. Prüfen Sie, ob statt eines Selection-Feldes eine Many2one-Relation zu einem Konfigurationsmodell sinnvoller wäre — damit können Anwender Optionen selbst pflegen, ohne Entwicklerinput.
3. Für Pflichtfelder immer einen Default setzen
Ist ein Selection-Feld required, sollten Sie einen sinnvollen Default angeben. Das verhindert Validierungsfehler bei automatischer Datenerzeugung, Importe oder API-Calls, wenn kein Nutzer den Wert setzt. Der Default sollte den häufigsten oder unkritischsten Zustand abbilden.
4. Erweiterungen mit selection_add umsetzen
Beim Hinzufügen von Optionen zu nativen Feldern nutzen Sie selection_add statt einer Neuimplementierung. Das ist kompatibler mit anderen Modulen. Ergänzen Sie ondelete, um das Verhalten bei Deinstallation sauber zu regeln.
5. Badge-Widget für bessere Sichtbarkeit in Listen verwenden
In Listen und Kanban ist der Standard-Output oft nur Text. Mit widget="badge" werden Werte als farbige Labels dargestellt, was insbesondere bei Statusfeldern die Scannbarkeit erheblich verbessert.
Häufige Fallstricke
Änderung eines Schlüssels zerstört vorhandene Daten
Labels lassen sich bedenkenlos anpassen, weil nur der Key gespeichert wird. Den Key selbst dürfen Sie nicht einfach umbenennen, sobald Datensätze diesen Wert enthalten: sonst zeigen alte Records keine gültige Anzeige mehr, und Domains/Automatisierungen mit dem alten Key funktionieren nicht mehr. Eine Key-Änderung erfordert immer eine Migration der bestehenden Daten.
Löschen einer Option hinterlässt verwaiste Datensätze
Wenn Sie eine Option entfernen, die noch in Datensätzen genutzt wird, erscheinen diese Datensätze mit fehlendem oder ungültigem Wert. Bevor Sie Optionen löschen, suchen Sie betroffene Einträge und aktualisieren oder archivieren Sie sie — das ist ein häufiger Fehler bei Datenbereinigungen.
Domain-Filter mit Label statt Key verwenden
Ein häufiger Fehler, besonders bei Anwendern, die Automatisierungen im UI anlegen, ist das Filtern nach dem sichtbaren Label statt nach dem Schlüssel. Solche Domains liefern stillschweigend null Ergebnisse und sind schwer zu debuggen. Prüfen Sie immer die Felddefinition, bevor Sie Filter oder Regeln anlegen.
Selection einsetzen, wo Many2one besser wäre
Wenn die Optionen häufig wechseln, Nutzer die Auswahl selbst pflegen sollen oder jede Option zusätzliche Attribute (Farbe, Reihenfolge, Kontozuordnung) braucht, ist eine Many2one-Relation zur Konfigurationstabelle die nachhaltigere Lösung. Selection-Felder eignen sich für stabile, entwicklerverwaltete Listen.
Leerwert nicht in serverseitiger Logik vergessen
Ein nicht-required Selection-Feld kann False sein. Wenn Sie in Python oder in Automatisierungen ohne Prüfung direkt auf String-Vergleiche setzen, führt das zu unerwartetem Verhalten. Prüfen und behandeln Sie explizit den leeren Zustand in Server-Aktionen und berechneten Feldern.
Fazit
Das Selection-Feld wirkt auf den ersten Blick simpel — seine richtige Nutzung entscheidet aber über Stabilität und Wartbarkeit einer Odoo-Instanz. Schlüssel vs. Label, der richtige Weg zum Erweitern und die Frage, ob Many2one nicht doch besser passt, sind Entscheidungspunkte, die spätere Probleme vermeiden.
Egal, ob Sie einen Vertragstyp in Studio anlegen, das Lieferfenster per Python-Modul definieren oder den Qualitätsstatus per API hinzufügen: Die beschriebenen Muster helfen Ihnen, die richtige Lösung für Ihren Use Case zu wählen.
Richtig eingesetzt ist das Selection-Feld ein Kerninstrument zur Sicherung von Datenqualität. Es hält Datensätze konsistent, Reports zuverlässig und Automatisierungen robust — wenn man seine Eigenheiten beachtet.
Bei Dasolo unterstützen wir Unternehmen dabei, Odoo bereichsübergreifend zu implementieren und zu optimieren. Ob Datenmodell-Design, Custom Fields oder die Entwicklung kompletter Module — unser Team berät und setzt um. Nehmen Sie Kontakt mit uns auf und lassen Sie uns über Ihr Odoo-Projekt sprechen.