RFE-4925: Add user preference for default Search filter type

[Alwinator]

Analysis / Root cause:

On the Search page, the filter dropdown lets users search resources by Label or by Name. The selection always defaults to Label on every page load, and there is no way to change that default. Users who primarily search by Name have to re-select it each time they open the Search page.

This adds a user preference so each user can choose which filter type is preselected on the Search page. The default behavior is unchanged (still Label) for users who don't set a preference.

Solution description:

• Added a new General tab user preference, "Default search filter", with options Label (default) and Name, stored under the user-settings key console.searchDefaultFilterType.
• Added a useSearchDefaultFilterType hook (mirroring the existing useExactSearch hook) that reads the preference via useUserPreference, defaulting to Label.
• Updated SearchFilterDropdown to read the preference and apply it to the dropdown's initial selected state. The default is applied once, gated on the preference's loaded flag, via a useRef guard so it never overrides a manual selection the user makes in the dropdown and avoids a flash of the wrong default.
• Ran yarn i18n to extract the new translatable strings into packages/console-app/locales/en/console-app.json.

Changed files:

• frontend/packages/console-app/console-extensions.json — new console.user-preference/item dropdown extension.
• frontend/packages/console-app/src/components/user-preferences/search/useSearchDefaultFilterType.ts — new hook.
• frontend/public/components/search-filter-dropdown.tsx — apply preferred default on load.
• frontend/packages/console-app/locales/en/console-app.json — extracted i18n keys.
• Tests (see below).

Screenshots / screen recording:

Test setup:

No special setup required.

1. Log in to the console.
2. (Optional) To verify persistence across reloads, ensure user settings are stored (ConfigMap or localStorage fallback).

Test cases:

• Default behavior: With no preference set, open Administration → Search (or the perspective's Search) — the filter dropdown defaults to Label.

• Set preference: Go to User Preferences → General → Default search filter, select Name. Open the Search page — the filter dropdown is preselected to Name.

• Switch back: Set the preference back to Label; the Search page dropdown defaults to Label again.

• Manual override is preserved: With the preference set to Name, open the Search page, then manually switch the dropdown to Label — it should not snap back to Name.

• Autosave: Changing the preference is autosaved (no explicit save action needed).

• Unit tests:

  • frontend/packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts
  • frontend/public/components/__tests__/search-filter-dropdown.spec.tsx

  Run with:

  cd frontend && yarn test packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts public/components/__tests__/search-filter-dropdown.spec.tsx

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

• The stored preference values (Label / Name) intentionally match the searchFilterValues enum so no mapping is required between the preference and the dropdown.
• No public/dynamic-plugin-SDK API changes; this uses the existing console.user-preference/item extension point.

Reviewers and assignees:

Console Approver:
/assign @openshift/team-ux-review

Docs approver:
/assign @openshift/team-ux-review

PX approver:
/assign @openshift/team-ux-review

Summary by CodeRabbit

• New Features

  • Added a Search-page user preference to set the default filter type (Label or Name) via a dropdown, with the preference applied on page load while still allowing manual override.

• Updates

  • Improved Search filter dropdown behavior to respect the asynchronously loaded default selection and track explicit user choices separately.
  • Updated Search page translations related to the new default filter setting.

[openshift-ci-robot]

@Alwinator: This pull request references RFE-4925 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature request to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Analysis / Root cause:

On the Search page, the filter dropdown lets users search resources by Label or by Name. The selection always defaults to Label on every page load, and there is no way to change that default. Users who primarily search by Name have to re-select it each time they open the Search page.

This adds a user preference so each user can choose which filter type is preselected on the Search page. The default behavior is unchanged (still Label) for users who don't set a preference.

Solution description:

• Added a new General tab user preference, "Default search filter", with options Label (default) and Name, stored under the user-settings key console.searchDefaultFilterType.
• Added a useSearchDefaultFilterType hook (mirroring the existing useExactSearch hook) that reads the preference via useUserPreference, defaulting to Label.
• Updated SearchFilterDropdown to read the preference and apply it to the dropdown's initial selected state. The default is applied once, gated on the preference's loaded flag, via a useRef guard so it never overrides a manual selection the user makes in the dropdown and avoids a flash of the wrong default.
• Ran yarn i18n to extract the new translatable strings into packages/console-app/locales/en/console-app.json.

Changed files:

• frontend/packages/console-app/console-extensions.json — new console.user-preference/item dropdown extension.
• frontend/packages/console-app/src/components/user-preferences/search/useSearchDefaultFilterType.ts — new hook.
• frontend/public/components/search-filter-dropdown.tsx — apply preferred default on load.
• frontend/packages/console-app/locales/en/console-app.json — extracted i18n keys.
• Tests (see below).

Screenshots / screen recording:

Test setup:

No special setup required.

1. Log in to the console.
2. (Optional) To verify persistence across reloads, ensure user settings are stored (ConfigMap or localStorage fallback).

Test cases:

• Default behavior: With no preference set, open Administration → Search (or the perspective's Search) — the filter dropdown defaults to Label.
• Set preference: Go to User Preferences → General → Default search filter, select Name. Open the Search page — the filter dropdown is preselected to Name.
• Switch back: Set the preference back to Label; the Search page dropdown defaults to Label again.
• Manual override is preserved: With the preference set to Name, open the Search page, then manually switch the dropdown to Label — it should not snap back to Name.
• Autosave: Changing the preference is autosaved (no explicit save action needed).
• Unit tests:
• frontend/packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts
• frontend/public/components/__tests__/search-filter-dropdown.spec.tsx

Run with:

cd frontend && yarn test packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts public/components/__tests__/search-filter-dropdown.spec.tsx

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

• The stored preference values (Label / Name) intentionally match the searchFilterValues enum so no mapping is required between the preference and the dropdown.
• No public/dynamic-plugin-SDK API changes; this uses the existing console.user-preference/item extension point.

Reviewers and assignees:

Console Approver:
/assign @openshift/team-ux-review

Docs approver:
/assign @openshift/team-ux-review

PX approver:
/assign @openshift/team-ux-review

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: ebedb2ec-c180-4ccd-9ae6-91a9f84664f6

📥 Commits

Reviewing files that changed from the base of the PR and between 312b8f0 and 7aa5d89.

📒 Files selected for processing (4)

• frontend/packages/console-app/console-extensions.json
• frontend/packages/console-app/locales/en/console-app.json
• frontend/packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts
• frontend/packages/console-app/src/components/user-preferences/search/useSearchDefaultFilterType.ts

✅ Files skipped from review due to trivial changes (1)

• frontend/packages/console-app/src/components/user-preferences/search/tests/useSearchDefaultFilterType.spec.ts

🚧 Files skipped from review as they are similar to previous changes (3)

• frontend/packages/console-app/console-extensions.json
• frontend/packages/console-app/src/components/user-preferences/search/useSearchDefaultFilterType.ts
• frontend/packages/console-app/locales/en/console-app.json

---

Walkthrough

This PR adds a new user preference enabling users to configure the default filter type on the Search page. The preference is declared in extension config with Label/Name dropdown options, implemented via a custom hook that retrieves and asynchronously loads the user's selection, and integrated into the SearchFilterDropdown component to apply the default while preserving manual user selections.

Changes

Search Default Filter Type Preference

Layer / File(s)	Summary
Preference declaration and translations frontend/packages/console-app/console-extensions.json, frontend/packages/console-app/locales/en/console-app.json	Registered the new user preference console.searchDefaultFilterType in the extension config with Label/Name dropdown options positioned after the exact search preference. Added i18n translations for the preference title, description, and option labels. Removed duplicate translation entries from unrelated sections.
Preference hook and unit tests frontend/packages/console-app/src/components/user-preferences/search/useSearchDefaultFilterType.ts, frontend/packages/console-app/src/components/user-preferences/search/__tests__/useSearchDefaultFilterType.spec.ts	Created useSearchDefaultFilterType hook that retrieves the preference via useUserPreference and returns the filter type string alongside a loaded state boolean. Unit tests verify correct hook initialization, argument passing, and return values for both loaded and not-loaded states.
SearchFilterDropdown integration and tests frontend/public/components/search-filter-dropdown.tsx, frontend/public/components/__tests__/search-filter-dropdown.spec.tsx	Updated component to import and use the preference hook for its default filter type. Refactored state management to track explicit user selection separately from the asynchronously loaded preference default. Tests confirm the dropdown respects the preference default and allows manual override.

Sequence Diagram

sequenceDiagram
  participant User
  participant SearchFilterDropdown
  participant useSearchDefaultFilterType
  participant useUserPreference
  User->>SearchFilterDropdown: Render
  SearchFilterDropdown->>useSearchDefaultFilterType: Call hook
  useSearchDefaultFilterType->>useUserPreference: Retrieve console.searchDefaultFilterType
  useUserPreference-->>useSearchDefaultFilterType: Return preference (Label/Name) + loaded state
  useSearchDefaultFilterType-->>SearchFilterDropdown: Return [filterType, loaded]
  SearchFilterDropdown->>SearchFilterDropdown: Set preferredDefault from loaded value
  SearchFilterDropdown-->>User: Display dropdown with default (Label or Name)
  User->>SearchFilterDropdown: Select filter type (optional)
  SearchFilterDropdown->>SearchFilterDropdown: Set userSelected override
  SearchFilterDropdown-->>User: Display user selection

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a user preference for the default Search filter type, which is the primary objective of the PR.
Description check	✅ Passed	The description is comprehensive and well-structured, covering analysis, solution, test cases, browser conformance, and additional notes. All required template sections are completed with sufficient detail.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	The PR contains only Jest/React Testing Library tests (TypeScript), not Ginkgo tests. The custom check applies to Ginkgo tests only, making it not applicable to this PR.
Test Structure And Quality	✅ Passed	The custom check is for Ginkgo (Go) tests, but this PR only adds Jest (JavaScript/TypeScript) tests. The check is not applicable to this frontend PR.
Microshift Test Compatibility	✅ Passed	No Ginkgo e2e tests are added in this PR. Changes are frontend-only (TypeScript/React components, hooks, and Jest unit tests). The custom check for MicroShift compatibility is not applicable.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	No Ginkgo e2e tests are added in this PR. All new tests are Jest unit tests (TypeScript/React), which are frontend component tests unrelated to SNO cluster topology checks.
Topology-Aware Scheduling Compatibility	✅ Passed	This PR is a frontend console UI change (React components, user preference configuration, i18n strings, tests) with no deployment manifests, operator code, controllers, or scheduling constraints. T...
Ote Binary Stdout Contract	✅ Passed	PR is frontend-only (TypeScript/React) with Jest and RTL tests; no Go code or Ginkgo tests present. OTE Binary Stdout Contract check applies only to Go/Ginkgo code, making it inapplicable here.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	No Ginkgo e2e tests are added in this PR. All changes are TypeScript/JSON frontend code with Jest unit tests, not Go-based integration tests.
No-Weak-Crypto	✅ Passed	PR adds user preferences for search filter selection. No cryptographic algorithms, custom crypto, or secret comparisons found in any modified files.
Container-Privileges	✅ Passed	This PR modifies only frontend UI code (TypeScript/React components and i18n strings), not container or Kubernetes configurations. The check for container privileges is not applicable to this front...
No-Sensitive-Data-In-Logs	✅ Passed	No logging statements or sensitive data exposure detected. The PR only handles user preference values ("Label"/"Name") with no passwords, tokens, API keys, PII, or debugging code.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 Biome (2.5.0)

frontend/packages/console-app/console-extensions.json

File contains syntax errors that prevent linting: Line 1893: Expected a property but instead found '// The query used to compute the number of kube-apiserver instances that are up'.; Line 1904: End of file expected; Line 1904: End of file expected; Line 1905: Expected an array, an object, or a literal but instead found '// API_SERVERS_UP'.; Line 1904: End of file expected; Line 1905: End of file expected; Line 1906: End of file expected; Line 1906: End of file expected; Line 1908: End of file expected; Line 1908: End of file expected; Line 1910: End of file expected; Line 1910: End of file expected; Line 1912: End of file expected; Line 1913: End of file expected; Line 1914: End of file expected; Line 1914: End of file expected; Line 1914: End of file expected; Line 1916: End of file expected; Line 1917: End of file expected; Line 1917: End of file expected; Line 1917: End of file expected; Line 1919: End of file expected; Line 1920: End of file expected; Line 1920: End of file expecte

... [truncated 2765 characters] ...

expected; Line 2717: End of file expected; Line 2727: End of file expected; Line 2728: End of file expected; Line 2738: End of file expected; Line 2739: End of file expected; Line 2749: End of file expected; Line 2750: End of file expected; Line 2755: End of file expected; Line 2756: End of file expected; Line 2766: End of file expected; Line 2767: End of file expected; Line 2777: End of file expected; Line 2778: End of file expected; Line 2788: End of file expected; Line 2789: End of file expected; Line 2799: End of file expected; Line 2800: End of file expected; Line 2812: End of file expected; Line 2813: End of file expected; Line 2823: End of file expected; Line 2824: End of file expected; Line 2834: End of file expected; Line 2835: End of file expected; Line 2846: End of file expected

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Alwinator
Once this PR has been reviewed and has the lgtm label, please assign vojtechszocs 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:

• frontend/OWNERS

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

[openshift-ci]

Hi @Alwinator. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[logonoff]

/ok-to-test

[openshift-ci]

@Alwinator: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-playwright	312b8f0	link	false	/test e2e-playwright

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.