Odoo module in depth

Install blipit_monitor 1.9 for Odoo 18 and 19

The Odoo guide under Install by platform gets you connected. This page covers everything the module does after that: how it picks who gets told, how multi-company access works, what it reports about logins, how it stays in sync, and what to do with a restored copy of production.

1Install and connect

Get blipit_monitor from apps.odoo.com or add the repository to your addons path (on Odoo.sh as a submodule), update the apps list and install Blipit Error Monitoring. Odoo Online does not allow third-party modules; Odoo.sh and on-premise do. In Settings, Blipit, paste the project's secret key (blipit_sk_...), tick 'I agree to the Blipit Terms of Service and the module licence' and Save. The module calls the activate endpoint with a fingerprint of database.uuid and shows 'Connected to <project> (<org>)'. It refuses a public key (403), a replaced key (401) and a database already registered elsewhere (409), each with the reason.

2People in charge

Each company has Blipit: people in charge. On a one-seat plan the settings page asks for a single person who covers every company; with more seats and one company it lists people for that company; with several companies it links to Configuration, People in Charge. Each person needs an email and access to the company, and gets the group Blipit: see reported issues. Every change is sent to Blipit, which counts distinct people against the plan's seats and refuses a list that adds people beyond them; Odoo then rolls the change back and shows the reason. Alerts for a new issue or a regression go to the people in charge of the event's company; an event with no company, or a company with nobody, goes to everyone in charge.

3Multi-company access

Every Python error carries the current company as a tag and the browser SDK does the same. Blipit keeps the companies seen per issue and the sync stores them. A record rule shows an issue to users allowed in one of its companies; issues with no company (scheduled actions, requests outside a company) are visible to everyone in the Blipit group.

4Regressions in Odoo

The Blipit app lists issues (unresolved by default; group by status, exception type or release). An issue that was fixed and came back says so at the top and tells the two cases apart: in the same release (the fix probably never shipped) or in a later release (something reintroduced it). Filters: Came back after a fix, Fix never shipped. Resolve, Ignore and Reopen write back to Blipit; Open in Blipit jumps to the dashboard.

5Login monitoring

Monitor interactive logins reports failed, blocked and (if Report successful logins is ticked) successful sign-ins with the login tried, database, IP, user agent and time; never the password. A fresh install has both ticked; an upgrade from an older version has them off until an administrator ticks them. It needs the Scale plan: on other plans ingest refuses and the module pauses for ten minutes and logs once. The client IP is right behind a proxy only when Odoo runs with --proxy-mode.

6Sync and refresh

The scheduled action Blipit: sync issues runs every ten minutes; Refresh from Blipit does it now. Issues deleted on the Blipit side are removed from Odoo. The people-in-charge list is re-sent on every sync so a changed email reaches Blipit within ten minutes. The plan and public key are re-read from Blipit at most every ten minutes by the background sender, never on a request or login path.

Good to know

  • Restored copies: a copy of production carries production's database.uuid and is refused with 409 'this database is already reporting to a different Blipit project'. Give the copy a new database.uuid (Settings, Technical, System Parameters) and connect it to its own project with its own key. Staging and production should always be two projects.
  • Errors are sent from a background thread through a queue of 100 events; a storm drops the rest with a warning, and a request is never slowed or failed by Blipit. UserError and AccessError are not sent because Odoo logs them without a traceback.
  • What leaves Odoo: errors, the request URL without its query string, the user's id and login, the company, and the sign-in attempts you enable. Passwords, session tokens and request bodies never do. The secret key never reaches a browser.
  • Frames under Odoo's own code and site-packages are marked as library frames, so grouping and suspect commits focus on your modules.
  • Version history: blipit.io/changelog. Support: support@blipit.io.

Stuck? Email support@blipit.io. Keys and the exact DSN for each project are under API keys in app.blipit.io.