Il modulo Odoo in dettaglio

1Installa e collega

Ottieni blipit_monitor da apps.odoo.com oppure aggiungi il repository al tuo addons path (su Odoo.sh come submodule), aggiorna l'elenco delle app e installa Blipit Error Monitoring. Odoo Online non consente moduli di terze parti; Odoo.sh e on-premise sì. In Impostazioni, Blipit, incolla la chiave segreta del progetto (blipit_sk_...), spunta 'Accetto i Termini di servizio di Blipit e la licenza del modulo' e Salva. Il modulo chiama l'endpoint activate con un fingerprint di database.uuid e mostra 'Connesso a <project> (<org>)'. Rifiuta una chiave pubblica (403), una chiave sostituita (401) e un database già registrato altrove (409), ognuno con il motivo.

2Responsabili

Ogni azienda ha Blipit: responsabili. Su un piano a una postazione la pagina delle impostazioni chiede una sola persona che copre ogni azienda; con più postazioni e una sola azienda elenca le persone per quell'azienda; con più aziende rimanda a Configurazione, Responsabili. Ogni persona ha bisogno di un'email e dell'accesso all'azienda, e riceve il gruppo Blipit: vedi le issue segnalate. Ogni modifica viene inviata a Blipit, che conta le persone distinte rispetto alle postazioni del piano e rifiuta un elenco che aggiunge persone oltre il limite; Odoo annulla quindi la modifica e mostra il motivo. Gli avvisi per una nuova issue o una regressione vanno ai responsabili dell'azienda dell'evento; un evento senza azienda, o un'azienda senza nessuno, va a tutti i responsabili.

3Accesso multi-azienda

Ogni errore Python porta con sé l'azienda corrente come tag e l'SDK per browser fa lo stesso. Blipit conserva le aziende viste per issue e la sincronizzazione le salva. Una regola di record mostra una issue agli utenti autorizzati in una delle sue aziende; le issue senza azienda (azioni pianificate, richieste fuori da un'azienda) sono visibili a tutti nel gruppo Blipit.

4Regressioni in Odoo

L'app Blipit elenca le issue (da risolvere per impostazione predefinita; raggruppa per stato, tipo di eccezione o release). Una issue che era stata corretta ed è tornata lo dice in cima e distingue i due casi: nella stessa release (la correzione probabilmente non è mai stata rilasciata) o in una release successiva (qualcosa l'ha reintrodotta). Filtri: Tornata dopo una correzione, Correzione mai rilasciata. Risolvi, Ignora e Riapri scrivono su Blipit; Apri in Blipit salta alla dashboard.

5Monitoraggio degli accessi

Monitora gli accessi interattivi segnala gli accessi falliti, bloccati e (se Segnala gli accessi riusciti è spuntato) riusciti con il login tentato, database, IP, user agent e ora; mai la password. Un'installazione nuova ha entrambi spuntati; un aggiornamento da una versione precedente li ha disattivati finché un amministratore non li spunta. Richiede il piano Scale: sugli altri piani l'ingest rifiuta e il modulo si mette in pausa per dieci minuti e registra un solo log. L'IP del client è corretto dietro un proxy solo quando Odoo gira con --proxy-mode.

6Sincronizzazione e aggiornamento

L'azione pianificata Blipit: sincronizza le issue gira ogni dieci minuti; Aggiorna da Blipit lo fa subito. Le issue eliminate lato Blipit vengono rimosse da Odoo. L'elenco dei responsabili viene reinviato a ogni sincronizzazione così un'email cambiata raggiunge Blipit entro dieci minuti. Il piano e la chiave pubblica vengono riletti da Blipit al massimo ogni dieci minuti dal sender in background, mai su un percorso di richiesta o di accesso.

Buono a sapersi

• Copie ripristinate: una copia della produzione porta con sé il database.uuid della produzione e viene rifiutata con 409 'this database is already reporting to a different Blipit project'. Assegna alla copia un nuovo database.uuid (Impostazioni, Tecnico, Parametri di sistema) e collegala a un progetto dedicato con la propria chiave. Staging e produzione dovrebbero sempre essere due progetti.
• Gli errori vengono inviati da un thread in background attraverso una coda di 100 eventi; una tempesta scarta il resto con un avviso, e una richiesta non viene mai rallentata o fatta fallire da Blipit. UserError e AccessError non vengono inviati perché Odoo li registra senza traceback.
• Cosa lascia Odoo: errori, l'URL della richiesta senza la query string, l'id e il login dell'utente, l'azienda e i tentativi di accesso che abiliti. Password, token di sessione e corpi delle richieste non escono mai. La chiave segreta non raggiunge mai un browser.
• I frame sotto il codice di Odoo stesso e site-packages sono segnati come frame di libreria, così raggruppamento e commit sospetti si concentrano sui tuoi moduli.
• Cronologia delle versioni: blipit.io/changelog. Supporto: support@blipit.io.