Odoo
Odoo-module in detail
Installeren blipit_monitor 1.9 for Odoo 18 and 19
De Odoo-handleiding onder Installeren per platform brengt je gekoppeld. Deze pagina behandelt alles wat de module daarna doet: hoe hij kiest wie wordt gewaarschuwd, hoe multi-company-toegang werkt, wat hij rapporteert over logins, hoe hij gesynchroniseerd blijft en wat je doet met een teruggezette kopie van productie.
1Installeren en koppelen
Haal blipit_monitor van apps.odoo.com of voeg de repository toe aan je addons-pad (op Odoo.sh als submodule), werk de lijst met apps bij en installeer Blipit Error Monitoring. Odoo Online staat geen modules van derden toe; Odoo.sh en on-premise wel. Plak in Instellingen, Blipit de geheime sleutel van het project (blipit_sk_...), vink 'Ik ga akkoord met de Blipit Servicevoorwaarden en de modulelicentie' aan en klik op Opslaan. De module roept het activate-endpoint aan met een fingerprint van database.uuid en toont 'Gekoppeld aan <project> (<org>)'. Hij weigert een publieke sleutel (403), een vervangen sleutel (401) en een database die al elders is geregistreerd (409), elk met de reden.
2Verantwoordelijken
Elk bedrijf heeft Blipit: verantwoordelijken. Op een plan met één seat vraagt de instellingenpagina om één persoon die elk bedrijf dekt; met meer seats en één bedrijf toont hij personen voor dat bedrijf; met meerdere bedrijven linkt hij naar Configuratie, Verantwoordelijken. Elke persoon heeft een e-mailadres en toegang tot het bedrijf nodig, en krijgt de groep Blipit: gerapporteerde issues bekijken. Elke wijziging wordt naar Blipit gestuurd, dat afzonderlijke personen afzet tegen de seats van het plan en een lijst weigert die daarboven personen toevoegt; Odoo draait de wijziging dan terug en toont de reden. Meldingen voor een nieuwe issue of een regressie gaan naar de verantwoordelijken van het bedrijf van het event; een event zonder bedrijf, of een bedrijf zonder verantwoordelijke, gaat naar alle verantwoordelijken.
3Multi-company-toegang
Elke Python-fout draagt het huidige bedrijf als tag en de browser-SDK doet hetzelfde. Blipit bewaart de bedrijven die per issue zijn gezien en de sync slaat ze op. Een record rule toont een issue aan gebruikers die toegang hebben tot een van zijn bedrijven; issues zonder bedrijf (geplande acties, requests buiten een bedrijf) zijn zichtbaar voor iedereen in de Blipit-groep.
4Regressies in Odoo
De Blipit-app toont issues (standaard onopgelost; groeperen op status, exception-type of release). Een issue die was opgelost en terugkwam, zegt dat bovenaan en onderscheidt de twee gevallen: in dezelfde release (de fix is waarschijnlijk nooit uitgerold) of in een latere release (iets heeft hem opnieuw geïntroduceerd). Filters: Teruggekomen na een fix, Fix nooit uitgerold. Oplossen, Negeren en Heropenen schrijven terug naar Blipit; Openen in Blipit springt naar het dashboard.
5Loginmonitoring
Interactieve logins monitoren rapporteert mislukte, geblokkeerde en (als Geslaagde logins rapporteren is aangevinkt) geslaagde logins met de geprobeerde login, database, IP, user agent en tijd; nooit het wachtwoord. Een verse installatie heeft beide aangevinkt; een upgrade van een oudere versie heeft ze uit totdat een beheerder ze aanvinkt. Het vereist het Scale-plan: op andere plannen weigert ingest en pauzeert de module tien minuten en logt één keer. Het client-IP klopt achter een proxy alleen als Odoo draait met --proxy-mode.
6Sync en vernieuwen
De geplande actie Blipit: issues synchroniseren draait elke tien minuten; Vernieuwen vanuit Blipit doet het nu. Issues die aan de Blipit-kant zijn verwijderd, worden uit Odoo verwijderd. De lijst met verantwoordelijken wordt bij elke sync opnieuw verstuurd, zodat een gewijzigd e-mailadres binnen tien minuten Blipit bereikt. Het plan en de publieke sleutel worden hoogstens elke tien minuten opnieuw uit Blipit gelezen door de achtergrondverzender, nooit op een request- of loginpad.
Goed om te weten
- Teruggezette kopieën: een kopie van productie draagt de database.uuid van productie en wordt geweigerd met 409 'this database is already reporting to a different Blipit project'. Geef de kopie een nieuwe database.uuid (Instellingen, Technisch, Systeemparameters) en koppel haar aan een eigen project met een eigen sleutel. Staging en productie moeten altijd twee projecten zijn.
- Fouten worden vanuit een achtergrondthread verstuurd via een wachtrij van 100 events; bij een storm wordt de rest weggegooid met een waarschuwing, en een request wordt nooit door Blipit vertraagd of onderbroken. UserError en AccessError worden niet verstuurd, omdat Odoo ze zonder traceback logt.
- Wat Odoo verlaat: fouten, de request-URL zonder query string, het id en de login van de gebruiker, het bedrijf en de inlogpogingen die je inschakelt. Wachtwoorden, sessietokens en request bodies nooit. De geheime sleutel bereikt nooit een browser.
- Frames onder de eigen code van Odoo en site-packages worden gemarkeerd als bibliotheekframes, zodat groepering en verdachte commits zich richten op jouw modules.
- Versiegeschiedenis: blipit.io/changelog. Support: support@blipit.io.
Kom je er niet uit? Mail support@blipit.io. Sleutels en de exacte DSN van elk project staan onder API-sleutels in app.blipit.io.

