Review the CRCPLAN parent feature for additional context, including the feature overview, goals, user stories and use cases, acceptance criteria, designs, dependencies, risks, assumptions, pending questions and documentation callouts.

Summary and goal

Users will be able to subscribe to notifications based off severity of events. Currently users cannot curate notifications based off severity and there have been several customer requests made for this feature in order to reduce notification noise.

Acceptance Criteria 

These conditions must be met for the epic to be considered complete. This provides a detailed definition of scope and the expected outcomes, written from a user's point of view.

User-Preferences Frontend

1. Subscribe by severity

• On the Notification Preferences (My Notifications) page, the user can subscribe only to events of a given severity (e.g. “only critical”) for a service via a clear control (e.g. “Select critical only” or equivalent).

• The user can subscribe to “all” events for a service and can “deselect all” for a service; counts (e.g. “Select critical only (4)”) reflect backend data.

• For each severity (e.g. Critical, Important, Moderate, Minor, None, Undefined), the user can choose notification cadence (e.g. Instant email, Daily digest email) and that choice is saved and reflected after reload.

• When the user sets a cadence for a severity, higher severities without an existing preference are auto-selected with the same cadence (cascading rule).

2. Bulk actions

• “Select critical only”, “Select all”, and “Deselect all” (or equivalent) are available at the correct scope (e.g. service or event card) and only affect that scope.

• “Deselect all” is disabled when there is no selection for that scope; it becomes enabled when there is at least one selection and clears only that scope when used.

• Bulk actions do not change preferences for other services or events outside the intended scope.

3. Data and persistence

• Severity-based subscription and cadence choices are loaded from and saved to the backend; after save, a full reload shows the same choices.

• Loading and error states are shown (e.g. spinners, disabled buttons, error messages), and failures do not leave the UI in an inconsistent state.

4. Documentation and telemetry

• Customer-facing documentation describes that users can subscribe by severity (e.g. only critical) and where to do it (Notification Preferences / My Notifications).

• Key actions (e.g. “Select critical only”, “Select all”, “Deselect all”, changing severity/cadence) are tracked; at least one report or dashboard can show usage of severity-based actions.

5. Quality

• E2E or integration tests cover: open Notification Preferences, use “Select critical only” (or equivalent), change at least one severity/cadence preference, save, and confirm persistence.

• Severity-related UI meets the project’s accessibility and internationalization standards (keyboard, screen reader, localized strings).

Notifications-Frontend

1. Event Log – severity filter

• The Event Log page has a Severity filter (dropdown or multi-select) in the toolbar alongside existing filters (e.g. Event, “Filter by event”, time range).

• Severity options align with the backend (e.g. Critical, Important, Moderate, Minor, None, Undefined, or the subset the API returns).

• Applying the severity filter restricts the table to events with the selected severity(ies); table and pagination update correctly.

• The Event Log table shows a Severity column with correct values and, if applicable, is sortable or has consistent ordering.

2. Behavior group wizard – severity filter (if in scope)

• In the “Associate event types” step of Create/Edit behavior group, the filter dropdown includes a Severity option (in addition to Event type, Service).

• The user can filter the event-type table by one or more severities; the table shows only matching event types and severity badges.

• Selection state and pagination work correctly when the severity filter is applied.

3. Data and behavior

• Event Log and behavior group wizard use backend/API data for event types and severities; filter results match API semantics.

• Loading and error states are shown where appropriate; filter changes do not leave the UI in an inconsistent state.

4. Quality

• E2E or integration tests cover: apply severity filter on Event Log and assert table content or count; apply severity filter in “Associate event types” and assert table filters correctly.
• New severity filter UI meets the project’s accessibility and internationalization standards.

api https://developers.redhat.com/api-catalog/api/notifications

mocks https://www.figma.com/design/tkdxV2TMYPlCMgHdfIAaQx/Severity-indicators-in-HCC-UI?node-id=0-1