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 one working week from confirmed scope depending on how many trigger points and conditional rules you need. Pricing starts from $999 (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.