Eigene Module einspielen: Git, Upload, Pfade

Was Sie vorab brauchen

• Die Betriebsart. Eigene Module und Module aus dem Apps Store laufen nach der Dokumentation 20.0 nur auf Odoo.sh und auf eigener Installation; mit Odoo Online sind sie unvereinbar, ausgenommen sind laut Store-FAQ Datenmodule ohne Python-Dateien (Hostingmodell wechseln).
• Rechte. Auf Odoo.sh Schreibrechte am GitHub-Repository, auf eigenem Server Zugang zu Dateisystem und Diensten, im Backend Administratorrechte und den Entwicklermodus in Odoo für die App-Liste.
• Der vollständige Modulordner mit __init__.py und __manifest__.py; der Modulname enthält nach der Dokumentation 20.0 nur Kleinbuchstaben, Ziffern und Unterstriche.
• Eine Sicherung mit Dateispeicher und eine Kopie für den Test: Odoo sichern: Backup-Strategie und Wiederherstellung, Testumgebung für Odoo.
• Ihr Addons-Pfad, bevor Sie Dateien ablegen.

Wohin die Moduldateien gehören

Die Betriebsart entscheidet Ablage und Aktivierung.

Betriebsart	Wo die Moduldateien liegen	Wie sie auf den Server kommen	Wie sie aktiviert werden
Odoo.sh	in einem Zweig des GitHub-Repositorys; Odoo.sh erkennt Ordner mit Odoo-Modulen	Push in den Entwicklungs- oder Staging-Zweig, Auslieferung per Merge in den Produktionszweig	Erstinstallation nach dem Merge in der App-Liste (Entwicklermodus, Apps ‣ App-Liste aktualisieren, Aktivieren); ein erhöhter Wert im Manifest-Feld version aktualisiert beim Merge ein bereits installiertes Modul, sonst Upgrade in der App-Liste
Eigene Installation (On-Premise)	in einem Verzeichnis des Addons-Pfads (addons_path)	Modulordner auf den Server kopieren	Dienst neu starten, App-Liste aktualisieren, Modul aktivieren
Odoo Online	keine eigenen Module und keine Apps-Store-Module; laut Store-FAQ nur Datenmodule ohne Python-Dateien	entfällt	entfällt

Schritt für Schritt: Odoo.sh

Auf Odoo.sh ist Git der Transportweg: Die Module liegen in einem Zweig des Projekt-Repositorys; die Plattform erkennt darin die Modulordner.

Schritt 1: Modul im Zweig ablegen

Klonen Sie das Repository und legen Sie den Modulordner darin ab, in der Wurzel oder gruppiert nach Bereichen. Das Grundgerüst erzeugt odoo-bin scaffold <modulname> ~/src/user/.

Ergebnis: Der Ordner mit __init__.py und __manifest__.py liegt im Zweig.

Schritt 2: Im Entwicklungszweig testen

Legen Sie im Reiter Zweige (Branches) einen Entwicklungszweig vom Produktionszweig an, oder pushen Sie lokal einen Zweig mit git checkout -b. Der Build legt eine Datenbank mit Demodaten an und führt die Tests aus; das Modul aktivieren Sie dort in der App-Liste.

Ergebnis: Der Zweig steht unter Entwicklung, die Datenbank ist über Verbinden erreichbar.

Schritt 3: Mit Produktivdaten prüfen

Ziehen Sie den Entwicklungszweig auf einen Staging-Zweig: Dieser Build dupliziert die Produktivdatenbank und läuft mit Ihrem Zweigstand. Das Modul installieren Sie dort in der App-Liste; ein Staging-Zweig installiert Module nicht von selbst, weil er die Produktivdatenbank nachbilden soll.

Ergebnis: Das Modul arbeitet mit echten Daten, ohne die Produktivdatenbank zu berühren.

Schritt 4: In Produktion ausliefern

Mergen Sie den Staging-Zweig in den Produktionszweig, per Ziehen oder mit git merge. Der Produktionsserver wird mit dem neuen Codestand aktualisiert und neu gestartet. Installieren Sie das Modul in der Produktionsdatenbank in der App-Liste: Entwicklermodus einschalten, Apps ‣ App-Liste aktualisieren, dann auf der Karte Aktivieren. Bei einem bereits installierten Modul löst ein erhöhter Wert im Feld version in __manifest__.py die Aktualisierung schon beim Merge aus; die Instanz ist während der Aktualisierung für Wartungsarbeiten nicht erreichbar. Ohne Versionserhöhung aktualisieren Sie in der App-Liste von Hand.

Ergebnis: Der Produktionszweig führt Ihren Code; was Aktivieren und Upgrade in der Datenbank auslösen, steht in Apps und Module installieren, entfernen.

Schritt 5: Fremdmodule als Submodul einbinden

Ein fremdes Modul aus einem eigenen Git-Repository binden Sie als Submodul an: git submodule add -b <zweig> <ssh-adresse> <pfad>, dann committen und pushen. Die Plattform erkennt Submodule und nimmt ihre Ordner in den Addons-Pfad auf. Ist das Repository privat, hinterlegen Sie in den Projekteinstellungen einen Deploy Key und tragen den öffentlichen Schlüssel im fremden Repository ein; Drittmodule auf Odoo.sh setzen laut Apps FAQ ein privates Projekt-Repository voraus.

Ergebnis: Nach dem nächsten Build steht der Ordner im Addons-Pfad und das Modul in der App-Liste; zur Auswahl siehe Prüfkriterien für Fremdmodule.

Schritt für Schritt: eigene Installation

Auf einem eigenen Server entscheidet der Addons-Pfad, welche Module Odoo findet.

Schritt 1: Addons-Pfad feststellen

Der Addons-Pfad steht als --addons-path auf der Kommandozeile oder als addons_path im Abschnitt [options] der Konfigurationsdatei: /etc/odoo.conf bei einer Paketinstallation, ~/.odoorc bei einer Quellinstallation, C:\Program Files\Odoo{VERSION}\server\odoo.conf unter Windows. Mehrere Verzeichnisse trennt ein Komma, und alle darin liegenden Ordner liest Odoo als Module ein. Zwei Beispiele aus der Dokumentation für den Aufbau des Pfads: /usr/lib/python3/dist-packages/odoo/addons beim Debian-Paket und, bei einer Quellinstallation mit geklontem Community- und Enterprise-Repository, die Pfade beider Verzeichnisse, wobei der Enterprise-Pfad vor den übrigen stehen muss, damit die Addons korrekt geladen werden, etwa /opt/odoo/enterprise,/opt/odoo/community/odoo/addons,/opt/odoo/community/addons. Eigene Verzeichnisse außerhalb der Standardpfade sind nötige Konfiguration, damit eigene Module geladen werden.

Ergebnis: Sie wissen, in welches Verzeichnis Ihr Modul gehört.

Schritt 2: Modulordner ablegen

Kopieren Sie den Modulordner in eines dieser Verzeichnisse; für ein gekauftes Modul nennt die Apps FAQ den Ordner aus dem ZIP-Archiv. Eigene Entwicklungen gehören in ein eigenes Verzeichnis, nicht in den Standardcode: Änderungen dort führen bei einer geklonten Installation in Update-Konflikte.

Ergebnis: Der Ordner mit __manifest__.py liegt in einem Verzeichnis, das Odoo einliest, und ist für den Dienstbenutzer lesbar.

Schritt 3: Dienst neu starten

Die Dokumentation nennt den Neustart des Dienstes als Abschluss der Aktualisierung; ein einzelner Lauf beendet den Server mit --stop-after-init selbst.

Ergebnis: Der Dienst läuft mit dem neuen Addons-Pfad.

Schritt 4: App-Liste aktualisieren und Modul aktivieren

Fehlt das Modul in der App-Liste, kann der Modulkatalog veraltet sein: Entwicklermodus einschalten, dann Apps ‣ App-Liste aktualisieren (Update Apps List) und Aktualisieren; danach aktivieren Sie das Modul auf seiner Karte.

Ergebnis: Die App-Liste zeigt das Modul und nach dem Aktivieren seine Menüs.

Schritt 5: Nach einer Änderung Dienst neu starten und Modul aktualisieren

Nach einer Quellcodeänderung folgt der Neustart: Die Anleitung für Quellcodeaktualisierungen schließt mit dem Neustart des Odoo-Dienstes oder einem Neustart des Rechners. Betrifft die Änderung die Struktur der Datenbank oder eine Ansicht, etwa ein neues Feld, kommt die Modulaktualisierung hinzu: In der App-Liste wählen Sie beim Modul Upgrade, auf der Kommandozeile aktualisiert odoo-bin -u <modul>, während odoo-bin -i <modul> ein Modul installiert; beide verlangen die Datenbankangabe -d (-u all für alle Module). Davor gehört die Sicherung aus dem nächsten Abschnitt dazu.

Ergebnis: Dienst und Datenbank arbeiten mit der neuen Fassung des Moduls; ein bereits installiertes Modul trägt danach die Version aus seinem Manifest.

So nehmen Sie einen Stand zurück

Erst sichern, dann zurücknehmen; die Reihenfolge entscheidet, ob Sie zurückkommen.

1. Sichern. Bei eigener Installation im Datenbankmanager unter /web/database/manager eine Sicherung als ZIP mit Dateispeicher; die Dokumentation weist diesen Bereich in Produktion dem Systemadministrator zu und rät, ihn an einem ins Internet gestellten System abzuschalten. Auf Odoo.sh vor der Auslieferung im Reiter Backups eine manuelle Sicherung: in Produktion und Staging möglich, drei Tage haltbar, höchstens fünf pro Tag.
2. Code zurücknehmen. Auf Odoo.sh greift die Plattform ein: Verhindert die Änderung den Neustart oder scheitert die Modulaktualisierung, steht der Server wieder auf der letzten erfolgreichen Codefassung, die Datenbank kehrt auf ihren vorherigen Stand zurück, und das Protokoll bleibt abrufbar. Bei eigener Installation nehmen Sie den Code selbst zurück: Die Dokumentation beschreibt das Aktualisieren der Installation als rücknehmbar, weil es die Datenbank nicht verändert, und nennt für eine geklonte Installation git reset --hard als Weg, lokale Änderungen zu verwerfen und die offizielle Fassung wiederherzustellen; den eigenen Modulordner setzen Sie auf die vorherige Fassung zurück.
3. Datenbank wiederherstellen. Der Code allein genügt nicht: Felder und Ansichten ändern die Struktur der Datenbank und brauchen dafür ein Modul-Update. Zurück kommen Sie über die Sicherung, im Datenbankmanager oder im Reiter Backups. Odoo.sh sichert die Produktivdatenbank automatisch und bewahrt sieben tägliche, vier wöchentliche und drei monatliche Stände; die Monatsstände erreichen Sie über den Odoo-Support.

Ein Modul-Update ist nicht das, was die Dokumentation ein Upgrade der Datenbank nennt: Damit ist der nicht umkehrbare Wechsel auf eine neue Odoo-Hauptversion über den Upgrade-Dienst gemeint, nicht das Einspielen eines eigenen Moduls.

So prüfen Sie das Ergebnis

1. App-Liste und Version. Filter Extra einschalten und die installierte Version mit dem Feld version im Manifest vergleichen.
2. Addons-Pfad auf Odoo.sh. Im Protokoll unter ~/logs/odoo.log die Zeile odoo: addons paths suchen; sie nennt die Pfade des laufenden Servers.
3. Wirkung im Test. Menüs, Berichte und Rechte zuerst im Staging-Zweig oder in der Kopie prüfen.
4. Sicherung. Eine Datei aus dem Dateispeicher, etwa ein Beleg-PDF, aus der Sicherung öffnen; fehlt sie dort, sichert Ihre Methode den Dateispeicher nicht mit.

Wenn etwas nicht klappt

Symptom	Ursache nach Dokumentation 20.0	Abhilfe
Das Modul fehlt in der App-Liste	Der Ordner liegt nicht im Addons-Pfad, der Server hat ihn noch nicht eingelesen, oder der Modulkatalog ist veraltet	Pfad prüfen, Dienst neu starten, dann im Entwicklermodus Apps ‣ App-Liste aktualisieren
Auf Odoo Online lässt sich das Modul nicht aktivieren	Odoo Online ist mit eigenen Modulen und Modulen aus dem Apps Store unvereinbar; ausgenommen sind Datenmodule ohne Python-Dateien	Modul auf Odoo.sh oder eigener Installation betreiben, siehe Hostingmodell wechseln
Nach dem Push ändert sich nichts	Das Modul ist in der Produktionsdatenbank noch nicht installiert, oder das Manifest-Feld version blieb gleich	Im Entwicklermodus Apps ‣ App-Liste aktualisieren und das Modul aktivieren; bei bereits installiertem Modul Upgrade wählen oder die Version erhöhen und erneut ausliefern
Der Server startet nach dem Push nicht, oder die Aktualisierung scheitert	Die Änderung verhindert den Neustart oder die Modulaktualisierung	Bei Odoo.sh nimmt die Plattform Code und Datenbank zurück; erst das Protokoll lesen, dann erneut ausliefern
Das Submodul fehlt auf Odoo.sh	Das fremde Repository ist privat und ohne Deploy Key angebunden	Deploy Key in den Projekteinstellungen erzeugen und im fremden Repository eintragen
Nach dem Zurücknehmen der Dateien stimmen die Daten nicht	Der Code ist zurückgenommen, die Datenbank nicht	Datenbank aus der Sicherung wiederherstellen

Wann Sie Hilfe holen sollten

• Sie benennen Felder, Modelle oder externe Bezeichner (XML-IDs) um: Dafür braucht es Upgrade-Skripte, sonst gehen Daten verloren; das gehört in das Vorgehen beim Wechsel auf eine neue Version.
• Ihr Projekt hat ein privates Fremd-Repository, mehrere Zweige oder eine Produktivdatenbank, die nur kurz ausfallen darf: Planen Sie den Merge mit dem Systemadministrator.
• Nach dem Zurücknehmen fehlen Daten, die Sie nicht gesichert haben: Die Wiederherstellung gehört in die Systemadministration.