Le module Odoo en détail

1Installer et connecter

Récupérez blipit_monitor depuis apps.odoo.com ou ajoutez le dépôt à votre addons path (sur Odoo.sh en tant que sous-module), mettez à jour la liste des applications et installez Blipit Error Monitoring. Odoo Online n'autorise pas les modules tiers ; Odoo.sh et l'installation sur site oui. Dans Paramètres, Blipit, collez la clé secrète du projet (blipit_sk_...), cochez « J'accepte les Conditions d'utilisation de Blipit et la licence du module » et Enregistrer. Le module appelle l'endpoint activate avec une empreinte de database.uuid et affiche « Connecté à <project> (<org>) ». Il refuse une clé publique (403), une clé remplacée (401) et une base de données déjà enregistrée ailleurs (409), chacune avec la raison.

2Responsables

Chaque société a des Blipit : responsables. Sur un plan à un siège, la page de paramètres demande une seule personne qui couvre toutes les sociétés ; avec plus de sièges et une seule société, elle liste les personnes de cette société ; avec plusieurs sociétés, elle renvoie vers Configuration, Responsables. Chaque personne doit avoir un e-mail et l'accès à la société, et reçoit le groupe Blipit : voir les problèmes signalés. Chaque modification est envoyée à Blipit, qui compte les personnes distinctes par rapport aux sièges du plan et refuse une liste qui ajouterait des personnes au-delà ; Odoo annule alors la modification et affiche la raison. Les alertes de nouveau problème ou de régression vont aux responsables de la société de l'événement ; un événement sans société, ou une société sans personne, va à tous les responsables.

3Accès multi-société

Chaque erreur Python porte la société courante comme tag et le SDK navigateur fait de même. Blipit conserve les sociétés vues par problème et la synchronisation les stocke. Une règle d'enregistrement montre un problème aux utilisateurs autorisés dans l'une de ses sociétés ; les problèmes sans société (actions planifiées, requêtes hors société) sont visibles par tout le groupe Blipit.

4Régressions dans Odoo

L'application Blipit liste les problèmes (non résolus par défaut ; regroupement par statut, type d'exception ou release). Un problème corrigé puis revenu l'indique en haut et distingue les deux cas : dans la même release (le correctif n'a probablement jamais été livré) ou dans une release ultérieure (quelque chose l'a réintroduit). Filtres : Revenu après correction, Correctif jamais livré. Résoudre, Ignorer et Rouvrir écrivent dans Blipit ; Ouvrir dans Blipit renvoie vers le tableau de bord.

5Surveillance des connexions

Surveiller les connexions interactives signale les connexions échouées, bloquées et (si Signaler les connexions réussies est coché) réussies avec l'identifiant essayé, la base de données, l'IP, le user agent et l'heure ; jamais le mot de passe. Une installation neuve a les deux cochés ; une mise à niveau depuis une version antérieure les laisse désactivés jusqu'à ce qu'un administrateur les coche. Cela nécessite le plan Scale : sur les autres plans, l'ingestion refuse et le module se met en pause dix minutes et logue une fois. L'IP du client n'est correcte derrière un proxy que si Odoo tourne avec --proxy-mode.

6Synchronisation et rafraîchissement

L'action planifiée Blipit : synchroniser les problèmes s'exécute toutes les dix minutes ; Rafraîchir depuis Blipit le fait immédiatement. Les problèmes supprimés côté Blipit sont retirés d'Odoo. La liste des responsables est renvoyée à chaque synchronisation pour qu'un e-mail modifié atteigne Blipit sous dix minutes. Le plan et la clé publique sont relus depuis Blipit au plus toutes les dix minutes par l'expéditeur en arrière-plan, jamais sur le chemin d'une requête ou d'une connexion.

Bon à savoir

• Copies restaurées : une copie de la production porte le database.uuid de la production et est refusée avec 409 « this database is already reporting to a different Blipit project ». Donnez à la copie un nouveau database.uuid (Paramètres, Technique, Paramètres système) et connectez-la à son propre projet avec sa propre clé. Le staging et la production doivent toujours être deux projets.
• Les erreurs sont envoyées depuis un thread en arrière-plan via une file de 100 événements ; une tempête écarte le reste avec un avertissement, et une requête n'est jamais ralentie ni mise en échec par Blipit. UserError et AccessError ne sont pas envoyées car Odoo les logue sans traceback.
• Ce qui quitte Odoo : les erreurs, l'URL de la requête sans sa query string, l'id et l'identifiant de l'utilisateur, la société, et les tentatives de connexion que vous activez. Les mots de passe, jetons de session et corps de requête ne partent jamais. La clé secrète n'atteint jamais un navigateur.
• Les frames sous le code d'Odoo lui-même et site-packages sont marquées comme frames de bibliothèque, pour que le regroupement et les commits suspects se concentrent sur vos modules.
• Historique des versions : blipit.io/changelog. Support : support@blipit.io.