feat: Add HeaderNotificationsSlot to enable notifications tray default ON by awais-ansari · Pull Request #663 · openedx/frontend-component-header

awais-ansari · 2026-03-06T12:36:40Z

Summery
Add a new HeaderNotificationsSlot plugin slot that renders NotificationsTray (from @edx/frontend-plugin-notifications) by default across all 5 header surfaces. This makes notifications available out-of-the-box for every Open edX community instance, while allowing operators to disable them via plugin slot configuration or the existing backend waffle flag.

Motivation
Currently, notifications in the header are enabled through tutor-contrib-platform-notifications, which injects NotificationsTray into 3 separate plugin slots:

Slots
org.openedx.frontend.layout.header_desktop_secondary_menu.v1 (Desktop Header)
org.openedx.frontend.layout.studio_header_search_button_slot.v1 (Studio Header)
org.openedx.frontend.layout.header_learning_help.v1 (Learning Header)

Problems with already implemented tutor-contrib-platform-notifications approach:

Mobile headers are missed entirely. Neither the LMS Mobile Header nor the Studio Mobile Header has notifications, so users on narrow viewports don't see the notification bell.
Not default-on. Community instances must install and configure tutor-contrib-platform-notifications to get notifications. Non-Tutor deployments require manual env.config.jsx configuration.
3 separate slot configs. Operators must configure 3 different slot IDs to enable one feature, and each slot is semantically unrelated to notifications (secondary menu, search button, help link).

Proposal

Create a single new HeaderNotificationsSlot with:

Slot ID: org.openedx.frontend.layout.header_notifications_tray.v1
Alias: header_notifications_tray
Default content: from @edx/frontend-plugin-notifications
Add @edx/frontend-plugin-notifications as a dependency (not peerDependency), so it bundles automatically

Insert this slot into all 5 header surfaces for authenticated users:

LMS Desktop
LMS Mobile
Learning
Studio Desktop
Studio Mobile

How Operators Can Disable Notifications

Option 1: Plugin slot config (env.config.jsx)

import { PLUGIN_OPERATIONS } from '@openedx/frontend-plugin-framework';

const config = {
  pluginSlots: {
    'org.openedx.frontend.layout.header_notifications_tray.v1': {
      keepDefault: true,
      plugins: [
        {
          op: PLUGIN_OPERATIONS.Hide,
          widgetId: 'default_contents',
        },
      ]
    },
  },
}

export default config;

Option 2:
Backend waffle flag - NotificationsTray is self-gating. It returns empty when the backend waffle flag is True. DISABLE_NOTIFICATIONS: True. Backend openedx/openedx-platform#38073

…t ON

codecov · 2026-03-06T12:39:47Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.81%. Comparing base (af6fe9f) to head (3c51082).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #663      +/-   ##
==========================================
+ Coverage   72.22%   72.81%   +0.59%     
==========================================
  Files          56       59       +3     
  Lines         504      515      +11     
  Branches      108      108              
==========================================
+ Hits          364      375      +11     
  Misses        137      137              
  Partials        3        3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

awais-ansari · 2026-03-09T11:32:11Z

I have tested it on LMS, Studio, and Mobile View.

brian-smith-tcril · 2026-03-10T19:00:14Z

I'd like to break down the problems listed with the current approach a bit:

Mobile headers are missed entirely. Neither the LMS Mobile Header nor the Studio Mobile Header have notifications, so users on narrow viewports don't see the notification bell.

I think this part should be a separate PR. I'm not sure if adding a bell to the already very limited space in the mobile header makes sense. It'd be good to get some design/product opinions on this feature.

Not default-on. Community instances must install and configure tutor-contrib-platform-notifications to get notifications. Non-Tutor deployments require manual env.config.jsx configuration.

It is my understanding that this is the main motivation for this change. Overall I agree with this PR's approach as a solution to this.

3 separate slot configs. Operators must configure 3 different slot IDs to enable one feature, and each slot is semantically unrelated to notifications (secondary menu, search button, help link).

I understand why this is frustrating, but the overall vision for slots is that they refer to places things can be put, not the default content in those places. I also know that isn't currently the case for quite a few existing slots (including org.openedx.frontend.layout.studio_header_search_button_slot.v1 and org.openedx.frontend.layout.header_learning_help.v1).

One of the reasons for this is that "where it goes" gives site operators more granular control over how each page/part of a page looks, instead of having one slot change how multiple pages/parts of pages look.

With that in mind, I think there's a way to get the best of both worlds here:

org.openedx.frontend.layout.header_desktop_secondary_menu.v1
- Add the notifications slot to the default content of the desktop secondary menu slot, before the existing default content (to match the behavior of the tutor plugin that uses priority 10). This will make it so site operators can remove the notification bell from this menu specifically if desired using org.openedx.frontend.layout.header_desktop_secondary_menu.v1. By putting HeaderNotificationsSlot in here instead of NotificationsTray directly, the "one slot for notifications" functionality can be preserved.

const DesktopSecondaryMenuSlot = ({
  menu,
}) => (
  <PluginSlot
    id="org.openedx.frontend.layout.header_desktop_secondary_menu.v1"
    idAliases={['desktop_secondary_menu_slot']}
    slotOptions={{
      mergeProps: true,
    }}
  >
+  <HeaderNotificationsSlot />
    <DesktopHeaderMainOrSecondaryMenu menu={menu} />
  </PluginSlot>
);

org.openedx.frontend.layout.studio_header_search_button_slot.v1
- For this one, I think it would make sense to make a new slot that wraps both the search button slot and the new notifications slot. This would ensure anyone currently using org.openedx.frontend.layout.studio_header_search_button_slot.v1 can continue to do so, the new notifications slot will work as intended, and site operators will have the option to modify the area with the search and notification buttons in studio only without touching the LMS if they'd like.
org.openedx.frontend.layout.header_learning_help.v1
- Same idea here as the search button slot.

Hopefully these thoughts/suggestions make sense! Please let me know if you have any questions!

awais-ansari · 2026-03-11T22:26:41Z

I'd like to break down the problems listed with the current approach a bit:

Mobile headers are missed entirely. Neither the LMS Mobile Header nor the Studio Mobile Header have notifications, so users on narrow viewports don't see the notification bell.

I think this part should be a separate PR. I'm not sure if adding a bell to the already very limited space in the mobile header makes sense. It'd be good to get some design/product opinions on this feature.

Not default-on. Community instances must install and configure tutor-contrib-platform-notifications to get notifications. Non-Tutor deployments require manual env.config.jsx configuration.

It is my understanding that this is the main motivation for this change. Overall I agree with this PR's approach as a solution to this.

3 separate slot configs. Operators must configure 3 different slot IDs to enable one feature, and each slot is semantically unrelated to notifications (secondary menu, search button, help link).

I understand why this is frustrating, but the overall vision for slots is that they refer to places things can be put, not the default content in those places. I also know that isn't currently the case for quite a few existing slots (including org.openedx.frontend.layout.studio_header_search_button_slot.v1 and org.openedx.frontend.layout.header_learning_help.v1).

One of the reasons for this is that "where it goes" gives site operators more granular control over how each page/part of a page looks, instead of having one slot change how multiple pages/parts of pages look.

With that in mind, I think there's a way to get the best of both worlds here:

org.openedx.frontend.layout.header_desktop_secondary_menu.v1

Add the notifications slot to the default content of the desktop secondary menu slot, before the existing default content (to match the behavior of the tutor plugin that uses priority 10). This will make it so site operators can remove the notification bell from this menu specifically if desired using org.openedx.frontend.layout.header_desktop_secondary_menu.v1. By putting HeaderNotificationsSlot in here instead of NotificationsTray directly, the "one slot for notifications" functionality can be preserved.
const DesktopSecondaryMenuSlot = ({
  menu,
}) => (
  <PluginSlot
    id="org.openedx.frontend.layout.header_desktop_secondary_menu.v1"
    idAliases={['desktop_secondary_menu_slot']}
    slotOptions={{
      mergeProps: true,
    }}
  >
+  <HeaderNotificationsSlot />
    <DesktopHeaderMainOrSecondaryMenu menu={menu} />
  </PluginSlot>
);
org.openedx.frontend.layout.studio_header_search_button_slot.v1

For this one, I think it would make sense to make a new slot that wraps both the search button slot and the new notifications slot. This would ensure anyone currently using org.openedx.frontend.layout.studio_header_search_button_slot.v1 can continue to do so, the new notifications slot will work as intended, and site operators will have the option to modify the area with the search and notification buttons in studio only without touching the LMS if they'd like.

org.openedx.frontend.layout.header_learning_help.v1

Same idea here as the search button slot.

Hopefully these thoughts/suggestions make sense! Please let me know if you have any questions!

@brian-smith-tcril Thank you for your detailed review and feedback. I have made the suggested changes. Please review it and let me know.

brian-smith-tcril

Thank you so much for addressing my previous comments! I'm very happy with this new structure!

I left quite a few comments, but they're pretty much all just README suggestions.

brian-smith-tcril · 2026-03-16T15:46:09Z

src/plugin-slots/LearningHeaderActionsSlot/index.jsx

+const LearningHeaderActionsSlot = () => (
+  <PluginSlot
+    id="org.openedx.frontend.layout.learning_header_actions.v1"
+    idAliases={['learning_header_actions_slot']}


This is a new slot so we shouldn't add any aliases

Suggested change

idAliases={['learning_header_actions_slot']}

brian-smith-tcril · 2026-03-16T15:47:09Z

src/plugin-slots/LearningHeaderActionsSlot/README.md

+### Slot ID Aliases
+* `learning_header_actions_slot`


This is a new slot so we shouldn't add any aliases

Suggested change

### Slot ID Aliases

* `learning_header_actions_slot`

brian-smith-tcril · 2026-03-16T15:56:55Z

src/plugin-slots/HeaderNotificationsSlot/index.jsx

+const HeaderNotificationsSlot = () => (
+  <PluginSlot
+    id="org.openedx.frontend.layout.header_notifications_tray.v1"
+    idAliases={['header_notifications_tray']}


This is a new slot so we shouldn't add any aliases

Suggested change

idAliases={['header_notifications_tray']}

brian-smith-tcril · 2026-03-16T16:04:23Z

src/plugin-slots/LearningHeaderActionsSlot/README.md

+
+### Disable Notifications in Learning Header Only
+
+The following `env.config.jsx` will hide the notification bell in the Learning header while keeping it in Desktop and Studio headers:


It'd be nice to add some context as to why this is needed as it's not the case for other slots. Explaining that the org.openedx.frontend.layout.header_notifications_tray.v1 slot is rendered in multiple places, so modifying that directly will impact more than just this location, would be good.

brian-smith-tcril · 2026-03-16T16:38:35Z

src/plugin-slots/LearningHeaderActionsSlot/README.md

+      plugins: [
+        {
+          op: PLUGIN_OPERATIONS.Hide,
+          widgetId: 'header_notifications_tray',


Suggested change

widgetId: 'header_notifications_tray',

widgetId: 'org.openedx.frontend.layout.header_notifications_tray.v1',

brian-smith-tcril · 2026-03-16T17:20:03Z

src/plugin-slots/HeaderNotificationsSlot/README.md

+## Migration from tutor-contrib-platform-notifications
+
+Sites currently using `tutor-contrib-platform-notifications` can remove these plugin configurations after upgrading to this version:
+
+- `org.openedx.frontend.layout.header_desktop_secondary_menu.v1` (notifications insertion)
+- `org.openedx.frontend.layout.studio_header_search_button_slot.v1` (notifications insertion)
+- `org.openedx.frontend.layout.header_learning_help.v1` (notifications insertion)


Aren't those being added by tutor-contrib-platform-notifications, so uninstalling/disabling the plugin should remove them?

brian-smith-tcril · 2026-03-16T17:22:19Z

src/plugin-slots/HeaderNotificationsSlot/README.md

+- `org.openedx.frontend.layout.studio_header_search_button_slot.v1` (notifications insertion)
+- `org.openedx.frontend.layout.header_learning_help.v1` (notifications insertion)
+
+Notifications will work out-of-the-box without any plugin configuration. If you want to disable them, follow the examples above.


This feels unrelated to the slot.

brian-smith-tcril · 2026-03-16T17:23:03Z

src/plugin-slots/DesktopSecondaryMenuSlot/README.md

+      plugins: [
+        {
+          op: PLUGIN_OPERATIONS.Hide,
+          widgetId: 'header_notifications_tray',


Suggested change

widgetId: 'header_notifications_tray',

widgetId: 'org.openedx.frontend.layout.header_notifications_tray.v1',

brian-smith-tcril · 2026-03-16T17:24:13Z

src/plugin-slots/DesktopSecondaryMenuSlot/README.md

@@ -1,3 +1,3 @@
 # Desktop Secondary Menu Slot


It'd be good to update screenshots on this one (and add one for hiding the notification bell)

brian-smith-tcril · 2026-03-16T17:26:48Z

src/plugin-slots/DesktopSecondaryMenuSlot/README.md

@@ -1,3 +1,3 @@
 # Desktop Secondary Menu Slot

 ### Slot ID: `org.openedx.frontend.layout.header_desktop_secondary_menu.v1`


I don't think we need to make a v2 of this slot, but I'd like to see if others have opinions on it.

@arbrandes thoughts?

I haven't reviewed the changes, but if they implement your suggestion of just modifying default content, then no, we shouldn't need to bump the version, as per FPF ADR 3.

feat: Add HeaderNotificationsSlot to enable notifications tray defaul…

dc8c58a

…t ON

awais-ansari requested a review from AhtishamShahid March 9, 2026 11:33

awais-ansari mentioned this pull request Mar 9, 2026

feat: default enable notification tray across all header openedx/frontend-plugin-notifications#79

Open

bmtcril requested a review from brian-smith-tcril March 9, 2026 13:36

bmtcril requested review from brian-smith-tcril and removed request for brian-smith-tcril March 11, 2026 14:14

refactor: Embed notifications in wrapper slots for better customization

3c51082

brian-smith-tcril reviewed Mar 16, 2026

View reviewed changes


		### Disable Notifications in Learning Header Only

		The following `env.config.jsx` will hide the notification bell in the Learning header while keeping it in Desktop and Studio headers:

	widgetId: 'header_notifications_tray',
	widgetId: 'org.openedx.frontend.layout.header_notifications_tray.v1',

		@@ -1,3 +1,3 @@
		# Desktop Secondary Menu Slot

		### Slot ID: `org.openedx.frontend.layout.header_desktop_secondary_menu.v1`

Conversation

awais-ansari commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problems with already implemented tutor-contrib-platform-notifications approach:

Proposal

How Operators Can Disable Notifications

Uh oh!

codecov bot commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

awais-ansari commented Mar 9, 2026

Uh oh!

brian-smith-tcril commented Mar 10, 2026

Uh oh!

awais-ansari commented Mar 11, 2026

Uh oh!

brian-smith-tcril left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

awais-ansari commented Mar 6, 2026 •

edited

Loading

codecov bot commented Mar 6, 2026 •

edited

Loading