Einleitung
Wenn Sie in Odoo schon einmal ein Produktbild hochgeladen, ein Logo gesetzt oder ein Mitarbeiterfoto eingefügt haben, sind Sie mit dem Image‑Feld in Berührung gekommen. Es ist eines der sichtbarsten Datenfelder im System und taucht an deutlich mehr Stellen auf, als viele Anwender vermuten.
Für Anwender wirkt das Ganze simpel: hochladen, speichern, fertig. Für Berater und Entwickler steckt jedoch mehr dahinter. Das Image‑Feld verwaltet Speicherung, Größenanpassungen und Zugriffsregeln — Details, die bei Customizing‑Projekten den Unterschied zwischen einer sauberen Lösung und späterem Mehraufwand ausmachen.
Dieser Leitfaden erklärt, welche Daten das Feld hält, wie Odoo damit umgeht, wie Sie es per Studio oder in Python hinzufügen und wie es sich in echten Geschäftsprozessen bewährt hat.
Was das Image-Feld in Odoo wirklich leistet
In modernen Odoo‑Versionen existiert ein eigener Feldtyp für Bilder: fields.Image. Vorher löste man Bilder mit allgemeinen Binary‑Feldern plus speziellen Widgets. Heute übernimmt fields.Image die gesamte Bildverarbeitung automatisch — vom Validieren bis zum Erzeugen von Vorschaubildern.
Technisch werden Bilddaten als binäre Inhalte (base64-kodiert) verwaltet. Statt große Byte‑Felder in jeder Tabelle zu behalten, legt Odoo die Dateien oft als Anhänge (ir.attachment) ab. Das entlastet die Kern‑Tabellen und erleichtert das Ausliefern von Bildern über Odoo‑URLs.
Darstellung in der Oberfläche
Im Formular erscheint das Image‑Feld als anklickbare Platzhaltergrafik: Nutzer laden Dateien hoch oder fügen in manchen Fällen eine URL ein und sehen sofort eine Miniatur‑Vorschau. Das schafft schnelle Orientierung beim Bearbeiten von Datensätzen.
In Listen werden Bilder aus Performance‑Gründen selten direkt angezeigt. Dafür sind Kanban‑Karten prädestiniert: dort liefern kleine Fotos oder Avatare nützliche visuelle Hinweise ohne die Übersicht zu überfrachten.
Image‑Feld gegenüber Binary‑Feld
Wichtig ist der Unterschied: Binary speichert beliebige Dateien (PDF, ZIP, Excel), Image ist speziell für Bilddateien gedacht. Image führt Bild‑Checks durch, skaliert automatisch und spielt mit dem Image‑Widget sauber zusammen. Für Dokumente bleibt Binary die richtige Wahl; für Fotos und Logos Image.
Wie das Feld technisch funktioniert
Upload‑Verarbeitung
Automatische Größenbegrenzung
Beim Speichern prüft Odoo hochgeladene Bilder und skaliert sie bei Bedarf. Dazu dienen Parameter wie max_width und max_height — die Proportionen bleiben dabei erhalten, die Anpassung läuft automatisch im Hintergrund.
Standardgrößen
Odoo setzt oft eine Obergrenze von 1920 Pixeln auf der längsten Seite. Deshalb heißen viele Standardfelder image_1920 in Modellen wie product.template oder res.partner: Sie speichern die große Variante, die für Detailansichten verwendet wird.
Mehrere Größen bereitstellen
Gängiges Muster ist, neben dem Hauptbild kleinere, verwandte Felder zu haben: image_1024, image_512, image_256, image_128. Diese Related‑Felder verweisen auf das Hauptbild, haben aber geringere Maximalmaße und werden bei Bedarf separat gespeichert.
So liefert die Anwendung immer die passende Bildgröße: Listen oder Produktübersichten greifen auf kleine Thumbnails, Detailseiten auf die große Variante. Bei Eigenentwicklungen entscheiden Sie, ob Sie dieses Mehrgrößen‑Schema brauchen – abhängig davon, wo Bilder gezeigt werden.
Ablage als Attachments
Standardmäßig legt Odoo Bilddaten als Attachments ab (ir.attachment). Der Datensatz selbst enthält dann nur einen Verweis. Das hält Tabellen schlanker und macht Bild‑URLs vorhersehbar, z. B. /web/image/product.template/42/image_1920 — nützlich für Website, E‑Mails und APIs.
Zugriffssteuerung
Bilder folgen den gleichen Zugriffsregeln wie ihr zugrundeliegender Datensatz. Hat ein Nutzer kein Leserecht für einen Artikel, kann er auch das Bild nicht abrufen. Diese Sicherheitsebene ist besonders wichtig, wenn Sie öffentliche Seiten oder Kundenportale bauen.
Typische Geschäfts-Anwendungsfälle
Wohin Image‑Felder im Alltag gehören
1. Produktkatalog (Vertrieb & Lager)
Produktbilder sind wohl der häufigste Einsatz: product.template beinhaltet standardmäßig image_1920 und die Bilder erscheinen im Webshop, auf PDF‑Belegen, im POS und auf mobilen Picking‑Bildschirmen.
Bei großen Katalogen ist es üblich, Bilder per API massenhaft hochzuladen statt manuell. Odoo akzeptiert base64‑kodierte Binärdaten, deshalb funktionieren XML‑RPC oder JSON‑RPC Uploads sehr zuverlässig.
2. Kunden‑ und Lieferantenlogos (CRM & Einkauf)
Das res.partner‑Modell nutzt ein Image‑Feld für Firmenlogos und Kontaktbilder. Diese Grafiken werden in Formularen, Chatter‑Bereichen und Kanban‑Ansichten angezeigt und helfen Vertriebsteams, schnell zu erkennen, mit wem sie es zu tun haben.
3. Mitarbeiterfotos (HR)
Mitarbeiterfotos landen im hr.employee‑Modell. Sie sind in Mitarbeiterlisten, in einigen Gehaltsabrechnungsansichten und neben Nachrichten in Discuss sichtbar. HR‑Teams importieren Fotos bei Onboarding oft automatisiert über Bulk‑Skripte.
4. Geräte- und Anlagenfotos (Maintenance)
Im Wartungsmodul lassen sich Bilder an Anlagen hängen. Servicetechniker profitieren davon: Ein Foto auf der Arbeitskarte hilft, die richtige Maschine vor Ort zu identifizieren.
5. Inspektions‑ oder Qualitätsformulare
Für Prüfprotokolle oder Lieferbestätigungen fügen Firmen gerne ein Image‑Feld hinzu, damit Monteure oder Fahrer vor Ort Fotobelege direkt am Datensatz ablegen können. Das funktioniert gleichermaßen gut per Studio oder Entwickler‑Code.
Image-Felder anlegen oder anpassen
Felder anlegen: Studio vs. Entwicklung
Zwei Wege führen zum Ziel: No‑Code über Odoo Studio oder Full‑Code durch ein Python‑Modul — je nach benötigtem Umfang und Kontrolle.
Mit Odoo Studio
Studio ist das integrierte Anpassungstool für Anwender und Berater. Im aktiven Studio‑Modus ziehen Sie ein Image‑Feld in das Formular, vergeben eine Beschriftung und Studio erzeugt das Feld automatisch auf dem Modell.
Studio‑Felder werden konventionell mit x_studio_ vorangestellt, etwa x_studio_site_photo, und verhalten sich wie native Image‑Felder bezüglich Speicherung und Anzeige.
Per Python entwickeln
Für technische Lösungen definieren Entwickler das Feld im Python‑Modell. So gewinnen Sie feine Kontrolle über Validierung, Größen und zusätzliche verwandte Felder.
Beispiel für ein Entwickler‑Setup
In der Entwicklungsvariante setzen Sie max_width und max_height, und erzeugen bei Bedarf ein getrenntes Thumbnail‑Feld als related‑Feld, z. B. photo_128. Das ist das etablierte Muster, um mehrere Bildgrößen pro Datensatz vorzuhalten.
Felder in Views einbinden
Damit Nutzer das Bild sehen und bearbeiten können, muss das Feld in einer View auftauchen. In XML‑Formularen nutzt man das image‑Widget für die Anzeige.
<field name="photo" widget="image" class="oe_avatar"/>Die CSS‑Klasse oe_avatar formatiert das Bild als runden Avatar oben links im Formular — typisch für Kontakt‑ oder Nutzerfotos. Alternativ lässt sich das Bild auch inline in Layouts platzieren.
Praktische Empfehlungen
Empfehlungen im Projektalltag
Angemessene Größenlimits festlegen
Die Standardgrenze von 1920 px ist für die meisten Anwendungsfälle sinnvoll. Größere Limits verbrauchen deutlich mehr Speicher und können Seiten langsamer machen; nur bei speziellen Anforderungen wie Druckgrafiken rechtfertigt sich eine Erhöhung.
Thumbnail‑Variante für Listen und Kanban
Wenn Bilder in Übersichten oder Kanban‑Karten sichtbar sein sollen, legen Sie eine kleine related‑Variante (128–256 px) an. Kleine Thumbnails reduzieren Ladezeiten gegenüber dem Abruf der großen Datei erheblich.
API für Massenimporte nutzen
Beim Befüllen von Hunderten oder Tausenden Datensätzen empfiehlt sich die automatisierte Lieferung per XML‑RPC/JSON‑RPC mit base64‑Daten statt manueller Eingabe. Das spart Zeit und reduziert Fehler.
Bilder vorkomprimieren
Odoo skaliert zwar, komprimiert aber nicht immer optimal. Ein vorab komprimiertes JPEG bleibt deutlich kleiner, was besonders bei großen Katalogen die Attachment‑Größe reduziert.
Bilder nicht in stark abgefragten Listen laden
Volle Bilddaten in Listenspalten führen zu langsamen Abfragen. Wenn Sie unbedingt ein Bild brauchen, verwenden Sie ein kleines Thumbnail; das Vollbild gehört in die Detailansicht.
Häufige Fehlerquellen
Typische Stolperfallen
Binary vs. Image verwechseln
Ein reines Binary‑Feld zeigt ohne Image‑Widget nur einen Download‑Button. Wer eine echte Vorschau will, muss entweder fields.Image verwenden oder explizit widget="image" im View setzen. Das Missverständnis kommt besonders in älteren Implementierungen vor.
Größenvarianten zu spät planen
Wer zuerst nur ein großes Bild anlegt und später Thumbnails braucht, steht vor Datenmigrationen. Planen Sie mehrere Größen von Anfang an, wenn Sie die Bilder an verschiedenen Stellen nutzen wollen.
Bilder direkt in Haupttabellen speichern
In alten oder falsch konfigurierten Systemen landen Binärdaten manchmal direkt in den Modelltabellen statt als Attachments. Das bläht die Datenbank auf und verlangsamt Abfragen. Achten Sie auf Attachment‑Storage oder S3‑Backends.
Image‑Felder als Dokumentenablage missbrauchen
Fotos sind ok, mehrseitige Scans oder Dokumentarchive gehören in das Documents‑Modul oder in Binary‑Felder mit Download‑Widget. Image‑Felder sind für Fotos und Logos gedacht, nicht für Dokumentenmanagement.
Zugriffsrechte für öffentliche Seiten vergessen
Wer Bild‑URLs in öffentlich zugänglichen Seiten nutzt, muss sicherstellen, dass die dazugehörigen Datensätze auch lesbar sind. Andernfalls gibt es beim Aufruf 404‑Fehler — ein häufiges Problem bei Portal‑ oder Website‑Bauten.
Fazit
Das Image‑Feld ist auf den ersten Blick trivial, birgt aber genug technische Details, um Projekte ohne Planung ins Stolpern zu bringen. Wer Resize‑Logik, Attachment‑Storage und das Variantenschema verstanden hat, arbeitet dauerhaft effizienter.
Für Anwender bedeutet das: Bilder liegen sicher am Datensatz und sind über vorhersehbare URLs verfügbar. Für Entwickler ist das Pattern fields.Image plus verwandte Thumbnails die bewährte Methode — je früher man es einsetzt, desto einfacher die Implementierung.
Egal ob Produktfoto, Baustellenaufnahme oder Firmenlogo: Mit dem Image‑Feld verwalten Sie visuelle Informationen konsistent und integriert innerhalb des Odoo‑Datenmodells.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Bei Dasolo unterstützen wir Unternehmen beim Implementieren, Anpassen und Optimieren von Odoo in allen Modulen. Ob Felder auf Standardmodellen konfigurieren, eigene Module entwickeln oder Datenmigrationen — wir arbeiten praktisch mit Ihrem Team, bis Odoo Ihre Geschäftsprozesse sauber abbildet.
Wenn Sie Fragen zu Ihrer Odoo‑Installation haben oder wissen möchten, welche Möglichkeiten die Plattform für Ihr Unternehmen bietet, kontaktieren Sie uns— wir helfen gerne weiter.