Odoo-Daten für Auswertungen freigeben: Lesezugriff und BI

Odoo führt seine Stamm- und Bewegungsdaten in einer PostgreSQL-Datenbank. Ein Auswertungswerkzeug erreicht sie auf zwei Wegen: über die Odoo-API, die jede Anfrage gegen die Rechte des angemeldeten Benutzers prüft, oder direkt aus der Datenbank, wo diese Prüfung fehlt. Welche Wege offenstehen, entscheidet vor allem das Hostingmodell.

Worauf es bei Auswertungen ankommt

Die Seite „System configuration“ der Dokumentation 20.0 beschreibt die Verbindung zwischen Odoo und PostgreSQL: Adresse, Port, den Datenbankbenutzer (db_user, db_password), die Netzfreigabe in pg_hba.conf und die Option db_sslmode für eine verschlüsselte Verbindung. Belege, Stammdaten und Buchungen liegen in dieser Datenbank.

Über die API bleibt Odoos Sicherheitsmodell in Kraft. Die Dokumentation der JSON-2-API schreibt, dass alle Operationen gegen die Zugriffsrechte, die Datensatzregeln und die Feldzugriffe des Benutzers geprüft werden; für dauerhafte Anbindungen empfiehlt sie einen eigenen Bot-Benutzer mit minimalen Rechten. Der Tarif entscheidet mit: Die Dokumentation nennt die externe API als Merkmal des Tarifs Custom und schließt One App Free und Standard aus. Diese Tarifregel gilt für die Odoo-Tarife (Odoo Online, Odoo.sh, On-Premise); für eine selbst betriebene Community-Installation nennt die Dokumentation keine Tarifregel, und den JSON-2-Endpunkt /json/2 führt dort der öffentliche Quellcode (Zweig 20.0, addons/rpc). Die Preisseite führt als typischen Fall externer Software ausdrücklich Programme an, die Daten aus Odoo für Berichte abfragen. Wie Sie Schlüssel und Bot-Benutzer anlegen, steht in API-Schlüssel und Zugriff für Schnittstellen in Odoo.

Der direkte Weg in die Datenbank umgeht die Rechteprüfung. Die Entwicklerdokumentation warnt, dass ein Zugriff am ORM vorbei unter anderem Zugriffsrechte und Übersetzungen überspringt und weniger sicher ist. Zwei Folgen treffen jede Auswertung: Werte, die Odoo erst zur Laufzeit berechnet, werden ohne store=True nicht gespeichert und haben keine Spalte in der Datenbank; eine SQL-Abfrage liest sie nicht unmittelbar aus und muss die Berechnung in einer eigenen Sicht nachbilden; und die Trennung mehrerer Gesellschaften beruht auf Datensatzregeln, die eine SQL-Abfrage nicht kennt (Datensatzregeln in Odoo, Mehrere Gesellschaften).

Welcher Zugangsweg zu welchem Hostingmodell passt

Die Übersicht gilt für Odoo 20.0, das die Support-Übersicht als im September 2026 erschienen führt, und für 19.0. Sie fasst zusammen, was die Dokumentation je Hostingmodell für Auswertungen anbietet.

Hostingmodell	Dokumentierter Weg zu den Daten	Bedingungen und Grenzen
Odoo Online	Auswertung in Odoo (Berichte, Dashboards, Tabellenkalkulation), Export von Listen, externe API (/json/2)	Externe API nur im Tarif Custom; die Sicherung laden Sie als ZIP über die Datenbankverwaltung herunter; große Exporte können laut Dokumentation in eine Zeitüberschreitung laufen, kleinere Stapel helfen; einen Zugang zur PostgreSQL-Datenbank nennt die Dokumentation nicht
Odoo.sh	Datenbankshell im Container (psql, über den Reiter „Shell“ oder SSH), Kopie in einem Staging-Zweig, Sicherungen im Projekt, externe API	Datenbankzugriff nur innerhalb der Shell; einen Zugriff auf PostgreSQL aus dem Netz beschreibt die Dokumentation nicht; Staging-Datenbanken werden nach einem Monat gelöscht; Produktionsshells sind ausdrücklich als riskant gekennzeichnet
On-Premise (eigener Server)	voller Zugang zu PostgreSQL: eigene Leserolle, Kopie oder Stand-by-Server (Stand-by beschreibt die PostgreSQL-Dokumentation, nicht Odoo), dazu API und Odoo-Berichte	Der Odoo-Datenbankbenutzer darf laut Dokumentation kein Superuser sein; Netzverbindungen regeln Sie selbst — die Dokumentation nennt SSL oder einen Tunnel; Rechte und Last begrenzen Sie selbst

Für Odoo Online beschreibt die Dokumentation keinen Zugang zur Datenbank; dort bleibt die API (Tarif Custom) oder eine heruntergeladene Sicherung. Bei Odoo.sh ist die Shell der dokumentierte Weg, und sie ist für die Produktion rot markiert: Die Dokumentation verweist für Versuche ausdrücklich auf Staging. Wie ein Auswertungswerkzeug bei diesen beiden Modellen an eine Netzverbindung kommt, sagt die Dokumentation nicht; das klären Sie mit dem Anbieter oder Ihrem Dienstleister, bevor Sie die Anbindung planen.

So richten Sie einen Lesezugriff ein

Auf einem selbst betriebenen Server legen Sie im PostgreSQL-Server eine eigene Rolle an. Das Beispiel ist eine Vorlage; Datenbankname, Netz und Fristen setzen Sie nach Ihren Gegebenheiten.

CREATE ROLE bi_lesen LOGIN PASSWORD '…' CONNECTION LIMIT 5;
GRANT pg_read_all_data TO bi_lesen;
ALTER ROLE bi_lesen SET default_transaction_read_only = on;
ALTER ROLE bi_lesen SET statement_timeout = '5min';

NOSUPERUSER und NOCREATEDB sind nach der Dokumentation die Voreinstellungen einer neuen Rolle; lassen Sie sie so. pg_read_all_data ist eine vordefinierte Rolle: Sie erlaubt das Lesen aller Tabellen, Sichten und Sequenzen, gilt auch für Tabellen, die ein Modul-Update später anlegt – ein zusätzliches ALTER DEFAULT PRIVILEGES ist dafür nicht nötig – und hebt Zeilensicherheitsregeln (Row Level Security) nicht auf. Wollen Sie nur einzelne Tabellen freigeben, nennen Sie sie einzeln in GRANT SELECT ON: GRANT SELECT ON odoo_prod.sale_order, odoo_prod.sale_order_line TO bi_lesen. Der Befehl GRANT SELECT ON ALL TABLES IN SCHEMA … ist dagegen die vollständige Freigabe eines Schemas: Er erfasst nach der PostgreSQL-Dokumentation alle vorhandenen Tabellen, Sichten und Fremdtabellen dieses Schemas. Für Tabellen, die später hinzukommen, setzen Sie die Voreinstellung mit ALTER DEFAULT PRIVILEGES FOR ROLE … IN SCHEMA … GRANT SELECT ON TABLES TO bi_lesen; sie gilt für Objekte, die die genannte Rolle danach anlegt. Noch schmaler wird der Zugang über eine eigene Sicht: Das Werkzeug liest nur die freigegebenen Spalten, und Sie behalten eine Zwischenschicht für Datenmodellwechsel.

Den Netzweg begrenzen Sie in pg_hba.conf, der Datei, die PostgreSQL laut Dokumentation für jede Verbindung auswertet. Die Odoo-Dokumentation zeigt als Beispiel host all all 192.168.1.0/24 md5 und lässt damit alle Rechner im Netz mit Passwort zu. Für ein einzelnes Auswertungswerkzeug tragen Sie nur dessen Adresse mit der Hostmaske /32 ein und verlangen eine verschlüsselte Verbindung, zum Beispiel hostssl odoo_prod bi_lesen 10.0.30.7/32 scram-sha-256. Soll ein ganzes Netz zugreifen, nennen Sie dessen Netzadresse nach dem Muster 10.0.30.0/24.

Beispielrechnung für die Last, mit angenommenen Zahlen: Ein Betrieb schreibt 300 Verkaufsaufträge je Arbeitstag mit durchschnittlich vier Positionen. Bei 240 Arbeitstagen sind das rund 288.000 Positionen im Jahr, nach drei Jahren etwa 864.000. Ein vollständiger Abzug liest jedes Mal alle diese Zeilen. Odoo führt an den Datensätzen die Felder create_date und write_date, solange der Log-Zugriff des Modells eingeschaltet ist (die Voreinstellung); mit einem Filter auf write_date seit dem letzten Lauf liest das Werkzeug nur die geänderten Sätze.

Typische Fehler

• Ein Konto mit Schreibrechten. Prüfen Sie die Rolle mit einer Testabfrage, die schreiben will: Sie muss mit „permission denied“ scheitern. default_transaction_read_only verhindert Änderungen an normalen Tabellen, aber laut Dokumentation nicht jeden Schreibvorgang auf die Platte – die Rechte bleiben die erste Schranke.
• Zugriff auf die ganze Datenbank statt auf drei Tabellen. Je breiter das Leserecht, desto mehr Daten sieht das Werkzeug, auch Lohn- und Personaldaten. pg_read_all_data ist ein Rundum-Leserecht; einzelne Tabellen oder eine Sicht sind enger.
• Kein Zeit- und Verbindungslimit. Lange Abfragen und dauerhaft offene Sitzungen belegen den Server, der auch die Belegerfassung bedient. statement_timeout bricht eine Abfrage nach der Frist ab, CONNECTION LIMIT deckelt die Sitzungen der Rolle.
• Direkt in der Produktionsdatenbank auswerten. Sicherer ist eine Kopie: Sicherung einspielen (Backup-Strategie für Odoo) oder ein Odoo.sh-Staging-Zweig. Beachten Sie dabei: Eine Kopie ist nur dann eine Testumgebung, in der geplante Aktionen und ausgehende E-Mails abgeschaltet sind, wenn sie neutralisiert ist — beim eigenen Einspielen bietet Odoo dafür die Option db load --neutralize, Odoo.sh-Staging-Zweige sind neutralisiert. Bei Odoo.sh löscht die Plattform die Staging-Datenbank nach einem Monat (Testumgebung für Odoo, Odoo.sh-Staging).
• Spaltennamen fest im Werkzeug verdrahtet. Prüfen Sie Ihre Abfragen nach jedem Odoo-Upgrade; das Datenmodell kann sich ändern. Eigene Sichten oder die API halten die Schnittstelle des Werkzeugs stabiler als der direkte Zugriff auf Basistabellen.

So gehen Sie vor

1. Prüfen Sie zuerst, ob Odoo die Auswertung selbst liefert: Berichte, Pivot-Tabellen und Dashboards lesen mit Odoos Rechteprüfung (Dashboards und Tabellen in Odoo).
2. Ordnen Sie Ihr Hostingmodell in die Tabelle oben ein und notieren Sie, welcher Weg dort vorgesehen ist.
3. Legen Sie ein eigenes Konto für das Werkzeug an: über die API einen Bot-Benutzer mit minimalen Rechten und einen Schlüssel mit Ablaufdatum, auf eigenem Server eine Leserolle.
4. Lesen Sie eine Kopie, wenn die Abfragen umfangreich sind: Sicherung einspielen — beim eigenen Einspielen nur neutralisiert (db load --neutralize) — oder Staging-Zweig. Bei Odoo Online führen Berichte und API über die Produktivdatenbank.
5. Begrenzen Sie Netzweg und Last: nur die Adresse des Werkzeugs in pg_hba.conf, verschlüsselte Verbindung, CONNECTION LIMIT und statement_timeout.
6. Prüfen Sie zum Schluss die Wirkung: Eine Schreibabfrage muss scheitern, ein Abbruch nach dem Zeitlimit muss im Serverlog stehen, und die Sitzungen der Rolle dürfen den Server nicht füllen.