Demodaten in Odoo: So baust du sie richtig

Hey, kennst du das? Du entwickelst ein neues Modul, alles läuft lokal wie geschmiert, und sobald du es auf einem frischen Odoo installierst — peng, keine Demodaten. Oder noch schlimmer: Die Tests schlagen fehl, weil irgendwas mit den Abhängigkeiten nicht stimmt. Frust pur. Deshalb lass uns heute mal ganz entspannt durchgehen, wie man Demodaten in Odoo wirklich sauber hinbekommt.

XML ist dein Freund — aber nur, wenn du ihn richtig fütterst

Demodaten gehören in Odoo traditionell in XML-Dateien im Ordner data oder demo. Der Unterschied? data wird bei jedem Update geladen, demo nur, wenn das Modul in einer Datenbank mit eingeschalteten Demo-Daten installiert wird. Für echte Demodaten also fast immer demo/.Ein simples Beispiel für einen Partner:

1
2
3
4
5

<record id="demo_partner_1" model="res.partner">
  <field name="name">Max Mustermann GmbH</field>
  <field name="email">max@mustermann.de</field>
  <field name="is_company">True</field>
</record>

Nichts Besonderes. Aber jetzt wird’s interessant.

Referenzieren wie ein Profi — external IDs sind Gold wert

Du willst, dass dein Demo-Produkt automatisch dem eben erstellten Partner zugewiesen wird? Dann brauchst du externe IDs.

1
2
3
4
5

<record id="demo_product_42" model="product.template">
  <field name="name">Super Produkt 3000</field>
  <field name="default_supplier_id" ref="demo_partner_1"/>
  ...
</record>

Mit ref="modulename.external_id" greifst du auf alles zu, was vorher geladen wurde. Und genau da kommt die Reihenfolge ins Spiel.

Die manifest.py ist kein Wunschkonzert — Reihenfolge ist alles

Wenn du mehrere Demo-Dateien hast, z. B. erst Partner, dann Produkte, dann Verkaufsaufträge, musst du das in der manifest.py explizit angeben:

1
2
3
4
5

 "demo": [
        "demo/partner_demo.xml",
        "demo/product_demo.xml",
        "demo/sale_order_demo.xml",
  ],

Warum das so wichtig ist? Odoo lädt genau in dieser Reihenfolge. Wenn dein Sale Order auf ein Produkt verweist, das erst später kommt — ReferenceError. Game over. Das Modul wird weiter installiert - jedoch ohne Demodaten.

Wenn XML allein nicht reicht — Python-Funktionen direkt aus der XML aufrufen

Manchmal brauchst du komplexere Logik: Preise berechnen, Seriennummern generieren, Angebote validieren. Dafür gibt’s:

1
2
3
4

  <function model="sale.order" name="action_confirm" eval="[[
            ref('sale_order_1'),
            ref('sale_order_2'),
            ]]"/>

Funktioniert super — und wird genau dann ausgeführt, wenn die XML-Datei dran ist.

Unit-Tests nicht kaputt machen – die goldene Regel

Odoo hat eine Menge eigener Unit-Tests, die auf den Standard-Demodaten von base, sale, stock & Co. laufen. Wenn du jetzt einfach ein neues Produkt in die Kategorie „All“ oder „All / Saleable“ reinhaust, kann es passieren, dass ein Unit Test Abrechnungsdaten zu einem Produkt ändern will und dieses für bestehende Produkte nicht mehr erlaubt ist. Lösung: Leg dir eigene Demo-Kategorien an. Ja, wirklich. Auch wenn’s ein bisschen mehr Arbeit ist.

Bonus: Demo-Konfigurationen, die wirklich was bringen

Willst du nicht nur Daten, sondern gleich eine lauffähige Konfiguration? Dann pack alles in demo/settings.xml:

1
2
3
4

<record model="ir.config_parameter" id="sale_coupon" forcecreate="False">
    <field name="key">custom_module.sale_coupon</field>
    <field name="value">True</field>
</record>

Wird nur im Demo-Modus geladen — perfekt für Kunden-Demos, Tests oder Screenshots.

Fazit? Nicht kompliziert, aber verdammt wichtig

Saubere Demodaten sind kein Nice-to-have. Sie sind der Unterschied zwischen “läuft bei mir” und “läuft beim Kunden”. Nimm dir die zehn Minuten, ordne deine Dateien richtig, nutze externe IDs konsequent und denk an die Tests. Und ehrlich gesagt — wenn du das einmal verinnerlicht hast, willst du nie wieder ohne.