Odoo-Modul im Detail

1Installieren und verbinden

Holen Sie blipit_monitor von apps.odoo.com oder fügen Sie das Repository zu Ihrem Addons-Pfad hinzu (auf Odoo.sh als Submodul), aktualisieren Sie die App-Liste und installieren Sie Blipit Error Monitoring. Odoo Online erlaubt keine Drittanbieter-Module; Odoo.sh und On-Premise schon. Fügen Sie unter Einstellungen, Blipit den geheimen Schlüssel des Projekts (blipit_sk_...) ein, haken Sie 'Ich stimme den Blipit-Nutzungsbedingungen und der Modullizenz zu' an und speichern Sie. Das Modul ruft den Activate-Endpoint mit einem Fingerprint der database.uuid auf und zeigt 'Verbunden mit <project> (<org>)'. Es lehnt einen öffentlichen Schlüssel (403), einen ersetzten Schlüssel (401) und eine bereits anderswo registrierte Datenbank (409) ab, jeweils mit Begründung.

2Verantwortliche Personen

Jedes Unternehmen hat Blipit: verantwortliche Personen. Auf einem Ein-Platz-Plan fragt die Einstellungsseite nach einer einzelnen Person, die alle Unternehmen abdeckt; mit mehr Plätzen und einem Unternehmen listet sie Personen für dieses Unternehmen; mit mehreren Unternehmen verlinkt sie auf Konfiguration, Verantwortliche Personen. Jede Person braucht eine E-Mail-Adresse und Zugriff auf das Unternehmen und erhält die Gruppe Blipit: gemeldete Issues sehen. Jede Änderung wird an Blipit gesendet, das die unterschiedlichen Personen gegen die Plätze des Plans zählt und eine Liste ablehnt, die Personen darüber hinaus hinzufügt; Odoo macht die Änderung dann rückgängig und zeigt den Grund. Alerts für ein neues Issue oder eine Regression gehen an die verantwortlichen Personen des Unternehmens des Events; ein Event ohne Unternehmen oder ein Unternehmen ohne Person geht an alle Verantwortlichen.

3Zugriff bei mehreren Unternehmen

Jeder Python-Fehler trägt das aktuelle Unternehmen als Tag, und das Browser-SDK macht dasselbe. Blipit merkt sich die pro Issue gesehenen Unternehmen, und die Synchronisierung speichert sie. Eine Datensatzregel zeigt ein Issue Nutzern, die in einem seiner Unternehmen berechtigt sind; Issues ohne Unternehmen (geplante Aktionen, Requests außerhalb eines Unternehmens) sind für alle in der Blipit-Gruppe sichtbar.

4Regressionen in Odoo

Die Blipit-App listet Issues (standardmäßig ungelöste; gruppieren nach Status, Exception-Typ oder Release). Ein Issue, das behoben war und zurückkam, sagt das oben und unterscheidet die beiden Fälle: im selben Release (der Fix wurde wahrscheinlich nie ausgeliefert) oder in einem späteren Release (etwas hat es wieder eingeführt). Filter: Nach Fix zurückgekehrt, Fix nie ausgeliefert. Beheben, Ignorieren und Wieder öffnen schreiben an Blipit zurück; In Blipit öffnen springt zum Dashboard.

5Anmeldeüberwachung

Interaktive Anmeldungen überwachen meldet fehlgeschlagene, blockierte und (wenn Erfolgreiche Anmeldungen melden angehakt ist) erfolgreiche Anmeldungen mit dem versuchten Login, Datenbank, IP, User Agent und Zeit; nie das Passwort. Eine Neuinstallation hat beides angehakt; ein Upgrade von einer älteren Version hat sie aus, bis ein Administrator sie anhakt. Es braucht den Scale-Plan: Auf anderen Plänen lehnt Ingest ab, und das Modul pausiert zehn Minuten und protokolliert einmal. Die Client-IP stimmt hinter einem Proxy nur, wenn Odoo mit --proxy-mode läuft.

6Synchronisieren und Aktualisieren

Die geplante Aktion Blipit: Issues synchronisieren läuft alle zehn Minuten; Von Blipit aktualisieren erledigt es sofort. Auf Blipit-Seite gelöschte Issues werden aus Odoo entfernt. Die Liste der verantwortlichen Personen wird bei jeder Synchronisierung erneut gesendet, sodass eine geänderte E-Mail-Adresse Blipit innerhalb von zehn Minuten erreicht. Plan und öffentlicher Schlüssel werden vom Hintergrund-Sender höchstens alle zehn Minuten von Blipit neu gelesen, nie in einem Request- oder Anmeldepfad.

Gut zu wissen

• Wiederhergestellte Kopien: Eine Kopie der Produktion trägt die database.uuid der Produktion und wird mit 409 'this database is already reporting to a different Blipit project' abgelehnt. Geben Sie der Kopie eine neue database.uuid (Einstellungen, Technisch, Systemparameter) und verbinden Sie sie mit einem eigenen Projekt und eigenem Schlüssel. Staging und Produktion sollten immer zwei Projekte sein.
• Fehler werden aus einem Hintergrund-Thread über eine Queue von 100 Events gesendet; ein Sturm verwirft den Rest mit einer Warnung, und ein Request wird von Blipit nie verlangsamt oder zum Scheitern gebracht. UserError und AccessError werden nicht gesendet, weil Odoo sie ohne Traceback protokolliert.
• Was Odoo verlässt: Fehler, die Request-URL ohne Query-String, ID und Login des Nutzers, das Unternehmen und die Anmeldeversuche, die Sie aktivieren. Passwörter, Session-Tokens und Request-Bodys nie. Der geheime Schlüssel erreicht nie einen Browser.
• Frames unter Odoos eigenem Code und site-packages werden als Bibliotheks-Frames markiert, damit sich Gruppierung und verdächtige Commits auf Ihre Module konzentrieren.
• Versionshistorie: blipit.io/changelog. Support: support@blipit.io.