Odoo ist eine hervorragende Basis für Geschäftsanwendungen – Sie haben Modelle, Benutzer, Zugriffsrechte, ein Portal…
Doch Benutzer erwarten heute, dass sich alles wie eine echte App auf dem Smartphone „anfühlt“: ein Symbol auf dem Startbildschirm, schnelle Reaktion und Benachrichtigungen, die auch dann erscheinen, wenn die App nicht geöffnet ist.
Hier kommt die Progressive Web App (PWA) auf Basis von Odoo ins Spiel.
Im Folgenden gehen wir die wichtigsten Schritte durch, mit denen Sie eine eigene kleine PWA-Schicht über dem Odoo-Portal aufbauen, inklusive Unterstützung für Benachrichtigungen.
Struktur eines Odoo-Moduls für die PWA
Zunächst ist es wichtig, das Projekt logisch zu organisieren.
Ein typisches Modul kann so aussehen:
pwa_custom/ │ ├── __init__.py ├── __manifest__.py │ ├── controllers/ │ ├── __init__.py │ └── main.py │ ├── models/ │ ├── __init__.py │ └── push_subscription.py │ ├── views/ │ ├── pwa_templates.xml │ └── assets.xml │ └── static/ └── src/ ├── js/ │ ├── pwa.js │ └── service_worker.js └── img/ └── icons/ ├── icon-192.png └── icon-512.png
Die Idee:
Odoo bleibt das Backend (Modelle, Logik), und dieses Modul ist eine dünne PWA-Schicht – Routen, Templates und JavaScript.
Die drei Kernbestandteile einer PWA
Damit sich ein beliebiges Portal wie eine progressive App verhält, sind drei Elemente nötig:
- Manifest – der Ausweis der App
- Service Worker – der Helfer im Hintergrund
- Sicheres Protokoll (HTTPS)
Sicheres Protokoll (HTTPS)
Das Manifest ist eine JSON-Datei, die dem Browser mitteilt:
- wie die App heißt
- welche URL die Startseite ist
- welche Symbole verwendet werden
- in welchem „Modus“ die App angezeigt wird (standalone, fullscreen…)
Minimales Beispiel:
{ "name": "Odoo portal aplikacija", "short_name": "Odoo app", "start_url": "/my/pwa", "display": "standalone", "background_color": "#ffffff", "theme_color": "#2563eb", "icons": [ { "src": "/pwa_custom/static/src/img/icons/icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "/pwa_custom/static/src/img/icons/icon-512.png", "sizes": "512x512", "type": "image/png" } ] }
Dieses JSON wird üblicherweise von einem Controller ausgeliefert, z. B. als /pwa/manifest.json.
Anschließend wird im gemeinsamen HTML-„Layout“ ein Link auf das Manifest eingefügt:
<link rel="manifest" href="/pwa/manifest.json" />
Ab diesem Moment weiß der Browser, dass Ihr Portal keine gewöhnliche Seite ist, sondern eine App, die auf dem Startbildschirm installiert werden kann.
2. Service Worker – Cache, Offline-Betrieb und Benachrichtigungen
Der Service Worker ist ein kleines Skript, das in einem eigenen Thread des Browsers läuft. Seine Hauptaufgaben:
- Caching von Ressourcen (CSS, JS, Hauptseiten)
- Anzeige grundlegender Inhalte, auch wenn das Netz „ausfällt“
- Empfang und Anzeige von Benachrichtigungen, die vom Server kommen
Die Registrierung des Service Workers sieht üblicherweise so aus (in pwa.js):
if ("serviceWorker" in navigator) { navigator.serviceWorker .register("/pwa-service-worker.js") .then(function (registration) { console.log("Service worker registered:", registration.scope); }) .catch(function (error) { console.error("Service worker registration failed:", error); }); }
In der Datei service_worker.js selbst legen Sie fest:
- was in den Cache kommt
- wie die App reagiert, wenn keine Internetverbindung besteht
- was passiert, wenn eine neue Nachricht vom Odoo-Backend eintrifft (Benachrichtigung)
3. HTTPS – Voraussetzung, damit alles funktioniert
Sowohl PWA als auch Benachrichtigungen erfordern ein sicheres Protokoll.
In der Praxis: Die Odoo-Anwendung muss über HTTPS laufen (Domain + Zertifikat). Ohne HTTPS erlaubt der Browser weder die Registrierung des Service Workers noch den Web-Push-Mechanismus.
Die PWA-Startseite im Portal
In der Odoo-Welt ist eine PWA vor allem als Portal-App sinnvoll: etwas, das Endbenutzer häufig auf dem Smartphone öffnen.
Deshalb ist der erste Schritt eine klare Startseite, typischerweise /my/pwa, die Folgendes anzeigt:
- anstehende Termine oder Aufgaben
- die neuesten Einträge (Bestellungen, Rechnungen, Tickets…)
- einen kurzen Statusüberblick (Dashboard)
Einige Leitlinien:
- alles muss auf einem Smartphone-Bildschirm gut lesbar sein
- ohne zu viele Klicks und unnötige Navigation
- aus PWA-Sicht ist dies der „Startbildschirm“ Ihrer App
Im Manifest setzen Sie dann start_url: "/my/pwa", damit die PWA immer auf dieser Seite startet.
Wie Benachrichtigungen im Browser funktionieren
Benachrichtigungen basieren auf dem Web-Push-Standard. Kurz gesagt:
- Die PWA fragt nach der Berechtigung: Der Browser fragt den Benutzer, ob er Benachrichtigungen zulässt.
- Stimmt der Benutzer zu, erzeugt der Browser ein sogenanntes Abonnement (Subscription) für dieses Gerät und diesen Browser.
- Die PWA sendet die Abonnementdaten an das Odoo-Backend.
- Das Backend speichert das Abonnement in einer Tabelle, die mit dem Benutzer verknüpft ist.
- Wenn in Odoo etwas Wichtiges passiert (bestätigter Termin, neue Nachricht, Statusänderung…), sendet das Backend eine Nachricht an alle Abonnements dieses Benutzers.
- Der Service Worker empfängt die Nachricht und zeigt sie als Benachrichtigung an, auch wenn der Browser minimiert ist.
Ein Abonnement sieht ungefähr so aus:
{ "endpoint": "https://push-service.example/...", "keys": { "p256dh": "PUBLIC_KEY_BASE64", "auth": "AUTH_SECRET_BASE64" } }
Diese Werte verwendet Odoo, wenn es eine neue Nachricht an dieses Gerät senden muss.
Was im Odoo-Backend ergänzt wird
Damit alles funktioniert, führt das PWA-Modul in Odoo üblicherweise einige Dinge ein:
-
ein Modell für Abonnements – eine Tabelle (z. B. pwa.push.subscription) mit den Feldern:
- Benutzer
- endpoint
- öffentlicher Schlüssel (p256dh)
- auth-Schlüssel
-
Routen für den Datenaustausch mit der PWA:
- eine Route, die den öffentlichen VAPID-Schlüssel zurückgibt, den das Frontend beim Abonnieren verwendet
- eine Route, an die das Frontend das Abonnement-JSON sendet, damit es in der Datenbank gespeichert wird
- Konfiguration der VAPID-Schlüssel – privater und öffentlicher Schlüssel werden in den Systemparametern von Odoo gespeichert
-
eine Hilfsmethode zum Senden von Benachrichtigungen – ein Codeabschnitt, der:
- alle Abonnements eines bestimmten Benutzers findet
- eine Web-Push-Nachricht mit kurzem Text und optionaler URL sendet
Ihr bestehender Geschäftscode (Modul für Termine, Bestellungen, Tickets…) ruft diese Hilfsmethode einfach dann auf, wenn ein für den Benutzer relevantes Ereignis eintritt.
Wie die PWA nützlich statt lästig wird
Der technische Teil ist lösbar, doch über den Erfolg der PWA entscheidet die Benutzererfahrung.
Einige praktische Tipps:
- Überhäufen Sie Benutzer nicht mit Benachrichtigungen. Senden Sie sie nur, wenn sie für den Benutzer wirklich etwas bedeuten: Bestätigung oder Änderung eines Termins, wichtige Erinnerung, neue Nachricht, wesentliche Statusänderung.
- Erklären Sie, warum Benachrichtigungen aktiviert werden sollten. Beschreiben Sie direkt auf der PWA-Seite in einem Satz, was der Benutzer davon hat: weniger verpasste Termine, schnellere Reaktion auf wichtige Änderungen und Ähnliches.
- Denken Sie an den Offline-Modus. Zeigen Sie statt eines leeren Bildschirms eine klare Meldung, dass der Benutzer gerade offline ist, aber die zuletzt verfügbaren Daten angezeigt werden.
- Verknüpfen Sie die Benachrichtigung mit der richtigen Seite. Lautet die Nachricht „Sie haben ein neues Dokument“, sollte ein Klick genau dieses Dokument oder die Liste der neuen Dokumente öffnen, nicht ein beliebiges Dashboard.
Fazit
Eine individuelle PWA auf Basis von Odoo bedeutet kein komplett neues Projekt, sondern eine dünne Schicht über dem bestehenden System:
- ein Modul mit klarer Struktur
- ein Manifest, das die App beschreibt
- ein Service Worker, der sich um Cache, Offline-Modus und Benachrichtigungen kümmert
- ein Modell und Routen in Odoo zum Speichern von Abonnements und Senden von Nachrichten
Das Ergebnis ist ein Odoo-Portal, das:
- sich wie eine App vom Startbildschirm öffnen lässt
- auch bei schwachem Netz zuverlässiger funktioniert
- den Benutzer per Benachrichtigung selbst „zurückruft“, wenn etwas Wichtiges passiert
So heben Sie ein bestehendes Odoo-System auf das Niveau eines modernen App-Erlebnisses, ohne separate mobile Apps entwickeln und pflegen zu müssen.