notification_alert

Odoo's Discuss can push native browser notifications for new messages, but a browser permission the user once denied silently kills them. notification_alert exists for exactly that failure mode: a view widget that checks the browser's Notification permission and, when the answer is denied, renders a centered alert telling the user notifications are blocked and where to fix it.

That is the entire widget. No options, no attributes, no fields read: the render condition is a getter over browser.Notification and the message text lives in the template. In any other permission state, granted, never asked, or a browser without the API, it renders nothing and takes no space.

Missed chat pings are a classic silent productivity leak: the user blocked notifications months ago, forgot, and now blames Odoo for messages they see hours late. A banner in the user's own preferences is the cheapest possible fix, no support ticket, no admin involvement, just a prompt at the one place users go when notification behavior puzzles them.

The placement history shows the intended pattern. Base puts it on the Preferences dialog; once HR's richer profile form takes over that screen, mail_bot_hr removes the original and pins the banner to the very top of the profile, first thing visible. If you build custom user-facing forms, the same two-line widget drop gives you the same early warning.

Dropping the banner into any form

<widget name="notification_alert"/>

Nothing else is needed; the widget decides for itself whether to render.

How mail_bot_hr repositions it

<!-- remove it from the simplified preferences -->
<widget name="notification_alert" position="replace"/>

<!-- pin it above the profile sheet -->
<sheet position="before">
    <widget name="notification_alert"/>
</sheet>

A textbook example of moving a view widget between inherited views without touching its code.

The widget's simplicity hides two things worth knowing. First, the permission check goes through Odoo's browser wrapper rather than the global directly, which keeps it testable, and it evaluates at render time: if the user fixes the browser setting, the banner disappears the next time the form renders, no reload of the session required, but also not live while the form is open.

Second, the check is inherently local. Notification permission belongs to the browser profile on that device, so the banner can correctly show for a user at their desk and correctly stay hidden for the same user at home. Administrators sometimes read that as flakiness; it is the browser model working as designed. The widget also renders nothing when the Notification API is absent entirely, private modes and some embedded webviews, so it never false-alarms where push cannot work anyway.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We read the widget's file on the public development branch at the time of writing; the branch is unstable and this page will be re-verified after release.

The component finally changes: the alert softens from alert-primary to alert-info, the copy is rewritten to explain the benefit of enabling notifications, and a small (?) button opens NotificationAlertDialog, a new core dialog added under web/static/src/core, presumably walking the user through re-enabling permission. The render condition itself, denied only, is unchanged.