Odoo gives you a thin toolbox for talking to users mid-workflow. raise UserError/ValidationError halts a transaction with a red block, self.env.user.notify_* shows a fleeting toast that vanishes before anyone reads it, and a wizard requires a whole transient.model plus a form view just to say "are you sure?". None of these let a functional consultant, without touching Python, decide that saving a sales order above a credit limit should show an amber warning the user must acknowledge, or that confirming a manufacturing order with a shortage should surface a clear alert with the exact missing components. Teams end up either over-blocking with hard errors or under-communicating with toasts nobody sees, and the important message — the one that prevents a costly mistake — gets lost.

Popup Message is a build-to-order module that gives your Odoo a proper, styled dialog layer: distinct success, warning, and alert (blocking) message boxes that render as OWL client-side dialogs and can be triggered declaratively from the events that matter to you. We model the message catalogue as a real models.Model with fields for message type, title, body (with QWuild QWeb/HTML rendering so you can interpolate record values like ${object.name} or the shortage list), target model, and trigger condition, secured with ir.model.access.csv plus record rules so only the right roles edit them. Triggers are wired to your chosen touchpoints: a server action or automated action (base.automation) on create/write, a Python @api.constrains gate on a specific field, a header button on a form, or a state transition on a status field. Because the messages live in data rather than hard-coded strings, an admin can edit copy, toggle a message on or off, or change its severity from the backend without a redeploy.

Under the hood the popups are rendered through Odoo's dialog service in the web client (OWL for 17/18/19), so they inherit your theme, respect right-to-left layouts, and behave consistently across desktop and the responsive backend — no jQuery-era hacks. Alert-type popups can be made truly blocking (the record won't save until acknowledged), warnings can require a typed reason that we log to the chatter or a dedicated audit field, and success popups can carry a call-to-action button that runs a follow-up action such as printing a QWeb report or opening the next record. Every trigger evaluation is domain-based and indexed so it adds negligible overhead, and the whole feature is exposed to automation and the external XML-RPC/JSON-RPC API where you need to raise a message programmatically from an integration.

Delivery is build-to-order: we start with a short scoping call, confirm exactly which models, events, and message rules you need, then build, test on a staging copy of your database, and hand over installable source. This is not an existing marketplace download — it is a module we assemble for your specific triggers and branding, so typical delivery is 2 to 4 weeks from confirmed scope depending on how many trigger points and conditional rules you need. Pricing starts from $249 (indicative, single-company base scope); more trigger points, multi-company message routing, complex conditional logic, deeper integrations, or Enterprise-specific views increase the quoted scope. You get a fixed quote after the scoping call, before any build work begins.