Approach: Making notifications tray default enabled
This is a proposal for making notifications tray default enabled upon Open edX installation.
Ulmo is the first release to have this feature but it has been live on edx.org for multiple release cycles and can therefore be considered stable.
As of today, tray is enabled using the frontend-plugin-notifications plugin, which injects the notifications tray into the Open edX header using the Open edX plugin framework.
This approach works well for organizations that use:
Open edX header (which already includes a plugin slot for tray)
Custom header (e.g., 2U) but with a plugin slot that can used to inject the
frontend-plugin-notificationsplugin.
As we propose to make it default enabled, we want to ensure:
No breaking changes for custom headers with plugin slot.
Compatibility with Tutor and non-Tutor deployments.
A sustainable long-term maintenance strategy for notification tray.
This document evaluates two possible approaches below.
Notification emails are not part of this proposal/discussion.
Approach 1: Permanently relocate plugin code to Open edX header
For this approach, we will need to:
Move the notification tray code directly into the Open edX header (
frontend-component-header).Change default state of
notifications.show_notifications_trayandnotifications.enable_notificationswaffle flags to ON.Deprecate the
frontend-plugin-notificationsplugin.Keep the waffle flag as a kill switch.
As a result:
Instances using the Open edX header will see notifications tray by default.
Instances that create their own custom header will need to manually add the notification tray code into their header and maintain it themselves.
Instances that are currently using custom header with notifications tray plugin (e.g.) will also need to manually add the notification tray code into their header and maintain it themselves.
Pros
Simplifies the MFE build (no plugin installation needed).
Smaller MFE deployment bundle.
Removes plugin lifecycle and dependency management.
Cons
Breaks instances that are using custom header because they do not share upstream header code.
Instances with custom headers must manually copy or reimplement the tray code in their own header.
Forces instances with custom headers to manually maintain notification tray code.
Approach 2: Pre-install notifications tray plugin in Open edX header
For this approach, we will need to:
Add notification tray plugin as permanent dependency in Open edX header.
Change default state of
notifications.show_notifications_trayandnotifications.enable_notificationswaffle flags to ON.Keep supporting the
frontend-plugin-notificationsplugin.Keep the waffle flag as a kill switch.
As a result:
Instances using the Open edX header will see notifications tray by default.
Instances that create their own custom header will need to add a plugin slot to the header and install
frontend-plugin-notificationsplugin.Instances that are currently using custom header with
frontend-plugin-notificationsinstalled (e.g. 2U) will see no change.
Pros
Fully backward-compatible for instances using custom headers.
Can support Tutor and non-Tutor deployments.
Preserves existing architecture pattern of plugin slots.
Cons
Slightly larger MFE bundle (plugin included).
Plugin lifecycle and dependency must be maintained.
Relevant resources
Slack conversation: https://openedx.slack.com/archives/C26T5JFDX/p1764132900021739
Comments
@Adolfo Brandes I would think this would be added as default content to the slot.
I am also in favor of Approach 2.
@Adolfo BrandesThanks for the thoughtful feedback, and +1 to your point about portability being a key benefit of the plugin architecture.
To answer your question about how the notifications plugin would be enabled by default in Approach 2:
Today, notifications are injected via three different plugin slots, depending on context (Studio header, learner header, default header). As part of this work, we’re planning to simplify and formalize this.
Introduce a dedicated notifications tray plugin slot
We will add a single, explicit slot in the header, e.g.
org.openedx.frontend.layout.header_notifications_tray.v1This slot will render the
NotificationsTrayas default content to the slot.
Flip the waffle flag semantics
The existing
show_notifications_trayflag will be replaced with something likehide_notifications_tray/disable_notifications_trayDefault value: false, meaning notifications are visible by default
Operators can opt out either by:
Setting the flag to true, or
Overriding/removing the slot via
env.config.jsx
Thank you for the explanation! I have no objections in principle, and I’m curious to look at the PR that introduces this new slot.
My vote is for Approach 2. What sells it for me is that I expect it’ll be easier to port it to the frontend-base header as a plugin rather than as a built-in frontend-component-header feature. (Which is not surprising, as one of the benefits of a plugin architecture is the potential for portability.)
The only question, which this document as far as I can see does not address, is, in Approach 2, how the React component(s) provided by frontend-plugin-notifications will be enabled by default. Is it just going to be added as default content to the slot? Or will operators (which include tutor-mfe) be expected to add it to their env.config.jsx?