feat: Add HeaderNotificationsSlot to enable notifications tray default ON

[awais-ansari]

Ticket

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 this approach:

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.
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

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #663      +/-   ##
==========================================
+ Coverage   72.22%   72.44%   +0.21%     
==========================================
  Files          56       57       +1     
  Lines         504      508       +4     
  Branches      108      109       +1     
==========================================
+ Hits          364      368       +4     
  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]

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

[brian-smith-tcril]

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!