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 user preference to customize the default search filter type on the Search page. Users can select Label or Name as their preferred default option. The selected preference will automatically apply when accessing the Search page, while users can still manually override it when needed.

[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: 6a6ee52c-3b19-4c2c-9d3e-c60279c1f3a1

📥 Commits

Reviewing files that changed from the base of the PR and between 534d254 and 312b8f0.

📒 Files selected for processing (6)

• 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
• frontend/public/components/__tests__/search-filter-dropdown.spec.tsx
• frontend/public/components/search-filter-dropdown.tsx

---

Walkthrough

This PR adds a new user preference enabling users to configure the default filter type on the Search page. The preference is declared with Label/Name dropdown options, implemented via a custom hook that retrieves and 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. Added i18n translations for the preference title, description, and option labels. Removed a duplicate translation entry.
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 use the preference hook for its default filter type. Introduced userSelected state to track explicit user choice and computed preferredDefault from the asynchronously loaded preference. Tests confirm the dropdown respects the preference default and allows manual override.

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, directly matching the changeset content.
Description check	✅ Passed	The description is comprehensive and complete, covering analysis, solution, test setup, test cases, browser conformance, and screenshots as required by the template.
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	PR contains only Jest tests (TypeScript/React), not Ginkgo tests. The check is inapplicable; it is designed for Go testing framework, not JavaScript. The Jest test names are all stable and determin...
Test Structure And Quality	✅ Passed	The custom check is designed for Ginkgo (Go) test quality, but this PR contains only Jest/TypeScript frontend tests. The check is not applicable to this PR's scope.
Microshift Test Compatibility	✅ Passed	PR contains only frontend Jest/React unit tests, no Ginkgo e2e tests. MicroShift compatibility check only applies to Ginkgo tests.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR adds only Jest unit tests for React components, not Ginkgo e2e tests. The SNO compatibility check applies only to Ginkgo tests, making it not applicable.
Topology-Aware Scheduling Compatibility	✅ Passed	PR only modifies frontend console UI code (React components, hooks, i18n, tests). No deployment manifests, operators, controllers, or scheduling constraints are introduced.
Ote Binary Stdout Contract	✅ Passed	PR contains only frontend changes (TypeScript, React, JSON). No Go files or process-level stdout writes present. OTE Binary Stdout Contract applies only to backend Go code, not frontend JavaScript/...
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	This PR contains no Ginkgo e2e tests. All changes are frontend TypeScript/JavaScript code and JSON configuration; tests are Jest/React unit tests, not Ginkgo tests. Check is not applicable.
No-Weak-Crypto	✅ Passed	PR contains no weak crypto algorithms (MD5, SHA1, DES, RC4, 3DES, Blowfish, ECB), custom crypto implementations, or non-constant-time secret comparisons. Changes are UI/preference-related only.
Container-Privileges	✅ Passed	This PR modifies only frontend files (TypeScript, React components, JSON config, and tests). It contains no container manifests, Kubernetes YAML, or Docker configurations, so the container-privileg...
No-Sensitive-Data-In-Logs	✅ Passed	No logging statements that expose sensitive data were found. Code contains only preference selection for filter types (Label/Name), which is not sensitive information.

_{✏️ 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.4.16)

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

File contains syntax errors that prevent linting: Line 1900: Expected a property but instead found '// The query used to compute the number of kube-apiserver instances that are up'.; Line 1911: End of file expected; Line 1911: End of file expected; Line 1912: Expected an array, an object, or a literal but instead found '// API_SERVERS_UP'.; Line 1911: End of file expected; Line 1912: End of file expected; Line 1913: End of file expected; Line 1913: End of file expected; Line 1915: End of file expected; Line 1915: 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 1921: End of file expected; Line 1921: End of file expected; Line 1921: End of file expected; Line 1923: End of file expected; Line 1924: End of file expected; Line 1924: End of file expected; Line 1924: End of file expected; Line 1926: End of file expected; Line 1927: End of file expected; Line 1927: End of file expecte

... [truncated 2765 characters] ...

expected; Line 2724: End of file expected; Line 2734: End of file expected; Line 2735: End of file expected; Line 2745: End of file expected; Line 2746: End of file expected; Line 2756: End of file expected; Line 2757: End of file expected; Line 2762: End of file expected; Line 2763: End of file expected; Line 2773: End of file expected; Line 2774: End of file expected; Line 2784: End of file expected; Line 2785: End of file expected; Line 2795: End of file expected; Line 2796: End of file expected; Line 2806: End of file expected; Line 2807: End of file expected; Line 2819: End of file expected; Line 2820: End of file expected; Line 2830: End of file expected; Line 2831: End of file expected; Line 2841: End of file expected; Line 2842: End of file expected; Line 2853: 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.

[openshift-ci]

PR needs rebase.

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.