feat: make default event severity filter configurable

[zyzzmohit]

Summary

This PR introduces a new configuration option to control the default state of the event severity filter on the cluster overview page.

Previously, the "Only warnings" filter defaulted to true, hiding normal events by default. This PR allows administrators to configure this default behavior globally via the backend CLI or Helm chart, improving visibility for users who prefer to see all events initially.

The implementation preserves user preference: if a user has manually toggled the filter, their choice is saved in localStorage and takes precedence over this global configuration.

Related Issue

Fixes #4566

Changes

• Backend:

  • Added FiltersWarningsOnly field to Config and HeadlampConfig structs.
  • Added a new CLI flag -filters-warnings-only (default: true to maintain backward compatibility).
  • Updated the /config API endpoint to expose this setting to the frontend.

• Frontend:

  • Updated Redux ConfigState to include filtersWarningsOnly.
  • Modified Overview.tsx to use this configuration value as the default state for the event filter switch (only used if no local user preference exists).

• Helm Chart:

  • Added config.events.warningsOnly to values.yaml.
  • Mapped this value to the HEADLAMP_CONFIG_FILTERS_WARNINGS_ONLY environment variable in deployment.yaml.

Steps to Test

Test Case 1: Default Behavior (Backward Compatibility)

1. Deploy Headlamp with default settings (or run locally without flags).
2. Open Headlamp in a new browser context (or clear localStorage key EVENT_WARNING_SWITCH_FILTER_STORAGE_KEY).
3. Navigate to any Cluster Overview page.
4. Observe: The "Only warnings" toggle should be ON by default.

Test Case 2: Configured to Show All Events

1. Deploy Headlamp with the Helm value config.events.warningsOnly: false (or run locally with go run ./cmd/... -filters-warnings-only=false).
2. Clear localStorage key EVENT_WARNING_SWITCH_FILTER_STORAGE_KEY to simulate a fresh user session.
3. Navigate to any Cluster Overview page.
4. Observe: The "Only warnings" toggle should be OFF by default, showing all events (Normal and Warning).

Screenshots (if applicable)

(Optional: You can attach a screenshot here showing the toggle in the OFF state by default)

Notes for the Reviewer

• The default value for this configuration is true, ensuring no change in behavior for existing deployments unless explicitly configured.
• This change affects the default state only; it does not prevent users from toggling the filter themselves.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: zyzzmohit
Once this PR has been reviewed and has the lgtm label, please assign illume for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Copilot]

Pull request overview

Adds a new backend-configurable default for the Cluster Overview “Only warnings” events filter, while keeping per-user overrides via localStorage.

Changes:

• Backend: introduces filters-warnings-only config/flag and exposes it via /config.
• Frontend: stores filtersWarningsOnly in Redux and uses it as the default for the events filter toggle (when no user preference exists).
• Helm: adds config.events.warningsOnly and passes it as a backend CLI arg.

Reviewed changes

Copilot reviewed 8 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
frontend/src/redux/configSlice.ts	Adds filtersWarningsOnly to Redux config state and attempts to hydrate it from /config.
frontend/src/components/cluster/Overview.tsx	Uses Redux filtersWarningsOnly as the default for the “Only warnings” toggle.
frontend/package-lock.json	Large lockfile churn (adds "peer": true entries broadly).
charts/headlamp/values.yaml	Adds Helm value config.events.warningsOnly (default true).
charts/headlamp/templates/deployment.yaml	Passes -filters-warnings-only arg from Helm values.
backend/pkg/headlampconfig/headlampConfig.go	Adds FiltersWarningsOnly (and PrometheusEndpoint) to runtime config struct.
backend/pkg/config/config.go	Adds FiltersWarningsOnly to parsed config and a new CLI flag.
backend/cmd/stateless.go	Includes FiltersWarningsOnly in the /parseKubeConfig response payload.
backend/cmd/headlamp.go	Extends /config response payload with filtersWarningsOnly (and prometheusEndpoint).

Files not reviewed (1)

• frontend/package-lock.json: Language not supported

Comments suppressed due to low confidence (1)

frontend/src/components/cluster/Overview.tsx:121

• The warning-only switch state is initialized from filtersWarningsOnly only once (in the useState initializer). Because the app doesn’t block rendering while /config is fetched, filtersWarningsOnly can update after this component mounts, but the switch state will not follow—so the admin-configured default may never apply for first-time users (no localStorage key). Consider syncing isWarningEventSwitchChecked when filtersWarningsOnly changes and no localStorage value exists, or derive the initial state lazily and update via an effect until the user explicitly toggles.

  const filtersWarningsOnly = useTypedSelector(state => state.config.filtersWarningsOnly);
  const EVENT_WARNING_SWITCH_DEFAULT = filtersWarningsOnly;
  const { t } = useTranslation(['translation', 'glossary']);
  const location = useLocation();
  const queryParams = new URLSearchParams(location.search);
  const eventsFilter = queryParams.get('eventsFilter');
  const filterFunc = useFilterFunc<Event>(['.jsonData.involvedObject.kind']);
  const [isWarningEventSwitchChecked, setIsWarningEventSwitchChecked] = React.useState(
    Boolean(
      JSON.parse(
        localStorage.getItem(EVENT_WARNING_SWITCH_FILTER_STORAGE_KEY) ||
          EVENT_WARNING_SWITCH_DEFAULT.toString()
      )
    )
  );

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

setConfig now requires filtersWarningsOnly, but multiple call sites dispatch setConfig({ clusters }) (e.g. auth chooser) and unit tests also call it without this field. This will break TypeScript builds/tests, and the !== undefined guard is currently inconsistent with the payload type. Make filtersWarningsOnly optional in the action payload (or accept a broader partial config payload) and keep the default in initialState when it’s omitted; update the reducer tests accordingly.

[Copilot]

FiltersWarningsOnly is added to the parsed Config and exposed as a CLI flag, but it also needs to be mapped into the runtime headlampconfig.HeadlampCFG (the struct used by /config via c.FiltersWarningsOnly). Currently the HeadlampCFG builder (in backend/cmd/server.go) does not set this field, so the value from flags/env will never reach the API response. Please wire conf.FiltersWarningsOnly into the HeadlampCFG construction so the frontend can receive the configured default.

[Copilot]

This argument directly renders .Values.config.events.warningsOnly without a default/with guard. If a user overrides config without the new events subtree (or sets it to {}), Helm can render <no value> here, producing an invalid -filters-warnings-only=<no value> flag and failing startup. Use default true (or conditionally emit the arg) to make the template robust.

[Copilot]

PrometheusEndpoint is now part of the /config response, but it doesn’t appear to be populated anywhere in the backend config parsing (no flags/env mapping found) and the frontend doesn’t reference prometheusEndpoint. If this field isn’t intentionally being introduced as part of this feature, consider removing it from clientConfig to avoid expanding the API surface with an always-empty value; otherwise ensure it’s properly configured and consumed.

Suggested change

PrometheusEndpoint string `json:"prometheusEndpoint"`

[Copilot]

Large, broad lockfile churn here adds "peer": true across many packages without any corresponding dependency changes in this PR. If the lockfile update isn’t required for the feature, it would be better to revert it (or regenerate it using the repo’s pinned Node/NPM versions) to keep the PR focused and reduce merge conflicts.

Suggested change

"peer": true,

[illume]

Thanks for this.

Please consider the review comments?

Also, please check the git commit messages match the format we use. See the git commit message guidelines in the contributing guide.

[zyzzmohit]

Thanks for the reviews! I've addressed the TypeScript compilation errors by making filtersWarningsOnly optional in the setConfig action and updating the storybook mocks. The build should pass now.

[zyzzmohit]

@illume Thanks for the guidance! I've addressed the feedback and cleaned up the branch:

• Rebased onto the latest main.
• Removed unrelated changes (stripped out the regeneratd docs, submodules, and package-lock.json churn).
• Squashed everything into a single clean commit following the project guidelines.
• Verified that the build and tests are passing.

Ready for another look :)