Skip to content

OCPBUGS-88739: Projects cannot be filtered by display name#16632

Open
cajieh wants to merge 1 commit into
openshift:mainfrom
cajieh:unable-filter-projects-by-displayname
Open

OCPBUGS-88739: Projects cannot be filtered by display name#16632
cajieh wants to merge 1 commit into
openshift:mainfrom
cajieh:unable-filter-projects-by-displayname

Conversation

@cajieh

@cajieh cajieh commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

The users are unable to filter projects by display name on the Projects list page ({{/k8s/cluster/projects}}) in the OpenShift 4.21 console. This functionality was available in previous versions. When a user types a project's display name (e.g., "My Test Project") in the filter toolbar, no results are shown even though a project with that display name exists. Only filtering by the actual project name ({{metadata.name}}) works.

Analysis / Root cause:
The migration to the new ConsoleDataView component likely lost the display name filtering capability for Projects and Namespaces.

Solution description:

  • Extracts display name from "openshift.io/display-name" annotation directly in the filter callback
  • Matches against both metadata.name OR display name

Screenshots / screen recording:
Before:
Screenshot 2026-06-16 at 9 59 04 AM
Screenshot 2026-06-16 at 9 59 11 AM

After:
Screenshot 2026-06-16 at 10 27 05 AM

  • Added displayName as an optional field to the ResourceMetadata type in internal-types.ts
  • Updated getK8sResourceMetadata in useConsoleDataViewFilters.ts to extract the display name from annotations
  • Updated the name matching logic to check both name OR displayName
  • Added unit tests to verify display name filtering works correctly for both fuzzy and exact search modes

Test setup:
N/A

Test cases:
N/A

Browser conformance:
N/A

Additional info:
N/A

Reviewers and assignees:

Summary by CodeRabbit

  • New Features
    • Filtering now matches against display names in addition to resource names, improving resource discoverability
    • Display name filtering supports both fuzzy (case-insensitive) and exact (case-sensitive) search modes

@openshift-ci openshift-ci Bot requested review from TheRealJon and sg00dwin June 16, 2026 15:38
@coderabbitai

coderabbitai Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

The name filter in useConsoleDataViewFilters is extended to match against the OpenShift openshift.io/display-name annotation in addition to metadata.name. A helper function getOpenShiftDisplayName and annotation constant are added. The matching function (matchFn) is now selected once based on isExactSearch. Tests cover fuzzy and exact-search modes for display-name filtering.

Changes

Display-name filter support

Layer / File(s) Summary
Display-name helper and filter predicate
frontend/packages/console-app/src/components/data-view/useConsoleDataViewFilters.ts
Adds OPENSHIFT_DISPLAY_NAME_ANNOTATION constant and getOpenShiftDisplayName helper; updates name filter to compute displayName, hoist matchFn selection outside the resource match check, and match when either metadata.name or displayName satisfies the query.
Test fixture and display-name filter tests
frontend/packages/console-app/src/components/data-view/__tests__/useConsoleDataViewFilters.spec.tsx
Adds projectMockData fixture with Projects carrying openshift.io/display-name and one without; extends test suite with fuzzy-mode cases (URL-encoded query, case-insensitivity, annotation-absent exclusion) and exact-mode cases (exact match returns single project, mismatched casing returns no results).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Test Structure And Quality ⚠️ Warning Tests use Jest (not Ginkgo), but the custom check for "assertion messages" is the primary quality issue: all assertions lack meaningful failure messages. Example: `expect(result.current.filteredDat... Add meaningful failure messages to all assertions using the second parameter to expect() or use Jest matchers that accept messages. For example: `expect(result.current.filteredData).toHaveLength(1, 'should match exactly one project by di...
✅ Passed checks (14 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: enabling project filtering by display name, which directly addresses the bug described in the PR.
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 modifies a Jest/TypeScript test file (.spec.tsx), not a Go/Ginkgo test file. The custom check is specific to Ginkgo tests and is not applicable to this PR, so it passes by inapplicability.
Microshift Test Compatibility ✅ Passed PR contains only Jest unit tests for a React frontend component, not Ginkgo e2e tests. The custom check applies only to Ginkgo e2e tests and is not applicable here.
Single Node Openshift (Sno) Test Compatibility ✅ Passed PR adds only frontend unit tests (Jest/React Testing Library) to test display-name filtering in a console component, not Ginkgo e2e tests. The check applies specifically to Ginkgo e2e tests, so it...
Topology-Aware Scheduling Compatibility ✅ Passed Check is not applicable. PR modifies only frontend console UI components (React hooks and tests), not deployment manifests, operators, or controllers. No scheduling constraints are introduced.
Ote Binary Stdout Contract ✅ Passed PR only modifies TypeScript/React frontend files (.tsx, .ts), not Go binaries or OTE test code. OTE Binary Stdout Contract applies only to Go process-level code (main, init, TestMain, etc.) and Gin...
Ipv6 And Disconnected Network Test Compatibility ✅ Passed PR contains no Ginkgo e2e tests; only Jest/React unit tests for frontend component. Check not applicable.
No-Weak-Crypto ✅ Passed PR contains no weak cryptographic algorithms, custom crypto implementations, or insecure secret comparisons—it only adds display name filtering using standard string matching utilities.
Container-Privileges ✅ Passed This PR contains only frontend TypeScript/React source code files (useConsoleDataViewFilters.ts and useConsoleDataViewFilters.spec.tsx), not Kubernetes manifests or container configurations. The co...
No-Sensitive-Data-In-Logs ✅ Passed No logging statements exposing passwords, tokens, API keys, PII, or sensitive data found in changes. Code adds filtering functionality with generic test data only.
Description check ✅ Passed The PR description comprehensively covers analysis, solution, screenshots, and test setup, though test cases and browser conformance sections are marked as N/A.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

@openshift-ci openshift-ci Bot added component/core Related to console core functionality component/sdk Related to console-plugin-sdk approved Indicates a PR has been approved by an approver from all required OWNERS files. plugin-api-changed Categorizes a PR as containing plugin API changes labels Jun 16, 2026
@cajieh cajieh changed the title Projects cannot be filtered by display name OCPBUGS-88739: Projects cannot be filtered by display name Jun 16, 2026
@openshift-ci-robot openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jun 16, 2026
@openshift-ci-robot

Copy link
Copy Markdown
Contributor

@cajieh: This pull request references Jira Issue OCPBUGS-88739, which is invalid:

  • expected the bug to target only the "5.0.0" version, but multiple target versions were set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Screenshots / screen recording:
Before:
Screenshot 2026-06-16 at 9 59 04 AM
Screenshot 2026-06-16 at 9 59 11 AM

After:
Screenshot 2026-06-16 at 10 27 05 AM

  • Added displayName as an optional field to the ResourceMetadata type in internal-types.ts
  • Updated getK8sResourceMetadata in useConsoleDataViewFilters.ts to extract the display name from annotations
  • Updated the name matching logic to check both name OR displayName
  • Added unit tests to verify display name filtering works correctly for both fuzzy and exact search modes

Test setup:
N/A

Test cases:
N/A

Browser conformance:
N/A

Additional info:
N/A

Reviewers and assignees:

Summary by CodeRabbit

Release Notes

  • New Features

  • Resources can now be filtered by display name, supporting both fuzzy and exact matching modes. Resources without display names are automatically excluded from display name searches.

  • Tests

  • Added test coverage for display name filtering functionality.

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.

@cajieh

cajieh commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

/jira refresh

@openshift-ci-robot openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jun 16, 2026
@openshift-ci-robot

Copy link
Copy Markdown
Contributor

@cajieh: This pull request references Jira Issue OCPBUGS-88739, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)
Details

In response to this:

/jira refresh

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 coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@frontend/packages/console-app/src/components/data-view/__tests__/useConsoleDataViewFilters.spec.tsx`:
- Around line 171-181: The exact-search test in the hook "should filter by
openshift.io/display-name using exact matching when exact search is enabled"
does not sufficiently validate true exact-match behavior. The current query
parameter of 'Test' expecting one result could pass even if substring matching
is used. Strengthen the test by using a full display-name value query in the
positive assertion case, and add a separate negative assertion that queries with
a partial string (that would match via substring but not exact matching) to
confirm it returns zero results when exact search is enabled. This ensures the
test catches regressions in exact-mode behavior.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: 43ba9643-a970-4b45-b68a-8903e6daa6b5

📥 Commits

Reviewing files that changed from the base of the PR and between 376c8a8 and 8199cc9.

📒 Files selected for processing (3)
  • frontend/packages/console-app/src/components/data-view/__tests__/useConsoleDataViewFilters.spec.tsx
  • frontend/packages/console-app/src/components/data-view/useConsoleDataViewFilters.ts
  • frontend/packages/console-dynamic-plugin-sdk/src/api/internal-types.ts

@cajieh cajieh force-pushed the unable-filter-projects-by-displayname branch from ea2528f to 8e181f1 Compare June 16, 2026 16:34
@openshift-ci-robot

Copy link
Copy Markdown
Contributor

@cajieh: This pull request references Jira Issue OCPBUGS-88739, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)
Details

In response to this:

Screenshots / screen recording:
Before:
Screenshot 2026-06-16 at 9 59 04 AM
Screenshot 2026-06-16 at 9 59 11 AM

After:
Screenshot 2026-06-16 at 10 27 05 AM

  • Added displayName as an optional field to the ResourceMetadata type in internal-types.ts
  • Updated getK8sResourceMetadata in useConsoleDataViewFilters.ts to extract the display name from annotations
  • Updated the name matching logic to check both name OR displayName
  • Added unit tests to verify display name filtering works correctly for both fuzzy and exact search modes

Test setup:
N/A

Test cases:
N/A

Browser conformance:
N/A

Additional info:
N/A

Reviewers and assignees:

Summary by CodeRabbit

Release Notes

  • New Features

  • Resources can now be filtered by display name using fuzzy or exact matching modes.

  • Display-name search respects each resource’s openshift.io/display-name annotation, excluding resources without it.

  • Tests

  • Added coverage for fuzzy and exact display-name matching, including URL-encoded names and scenarios where display name differs from resource name.

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.

@cajieh cajieh force-pushed the unable-filter-projects-by-displayname branch 2 times, most recently from e8e1ee9 to 7e037de Compare June 16, 2026 18:01

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@frontend/packages/console-app/src/components/data-view/__tests__/useConsoleDataViewFilters.spec.tsx`:
- Around line 173-195: The tests for exact matching behavior (at lines 173-195)
are not truly validating exact matching because the `useExactSearch` mock is
configured with substring semantics using `.includes()`. To fix this, update the
mock configuration for exact-mode tests to use strict equality checking instead
of substring matching, or add a negative test assertion that would fail under
substring semantics (for example, assert that a partial match like "my test"
returns zero results while "My Test Project" returns one result). This ensures
that exact-mode regressions cannot slip through and the tests actually validate
the intended exact-matching behavior rather than substring matching behavior.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: 26dd1e4a-8f1a-4c9d-b02e-dee7d2fd082a

📥 Commits

Reviewing files that changed from the base of the PR and between e8e1ee9 and 7e037de.

📒 Files selected for processing (3)
  • frontend/packages/console-app/src/components/data-view/__tests__/useConsoleDataViewFilters.spec.tsx
  • frontend/packages/console-app/src/components/data-view/useConsoleDataViewFilters.ts
  • frontend/packages/console-dynamic-plugin-sdk/src/api/internal-types.ts
🚧 Files skipped from review as they are similar to previous changes (2)
  • frontend/packages/console-dynamic-plugin-sdk/src/api/internal-types.ts
  • frontend/packages/console-app/src/components/data-view/useConsoleDataViewFilters.ts


const createWrapper = (initialEntries: string[] = ['/']): FC<{ children: ReactNode }> => {
const Wrapper: FC<{ children: ReactNode }> = ({ children }) => (
<MemoryRouter initialEntries={initialEntries}>{children}</MemoryRouter>

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since useConsoleDataViewFilters only depends on React Router, using the heavy renderHookWithProviders setup is unnecessary here. I've opened CONSOLE-5360 to introduce a lightweight renderHookWithRouter helper in a follow-up PR to clean up this boilerplate.

@cajieh

cajieh commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

/retest

@cajieh

cajieh commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-console

/test e2e-playwright

@rhamilto

Copy link
Copy Markdown
Member

Thanks for fixing this regression! One suggestion: the displayName addition to ResourceMetadata in internal-types.ts is a public plugin API change, but it isn't necessary here. The previous implementation on release-4.20 handled display name filtering entirely within the project-name filter function in table-filters.ts without exposing displayName on any shared type.

You could keep this fix internal by extracting the display name directly inside the filter callback in useConsoleDataViewFilters.ts (e.g., reading obj.metadata?.annotations?.['openshift.io/display-name'] alongside the existing getObjectMetadata call) rather than threading it through ResourceMetadata. That would avoid the SDK type change and the plugin-api-changed label.

@cajieh cajieh force-pushed the unable-filter-projects-by-displayname branch from 7e037de to e32b807 Compare June 17, 2026 12:39
Restore display-name matching in useConsoleDataViewFilters to match
legacy project-name filter behavior after Projects list migration to
ConsoleDataView.

Co-authored-by: Cursor <cursoragent@cursor.com>
@cajieh cajieh force-pushed the unable-filter-projects-by-displayname branch from e32b807 to 9795a13 Compare June 17, 2026 12:43

@rhamilto rhamilto left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jun 17, 2026
@openshift-ci

openshift-ci Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cajieh, rhamilto

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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

@openshift-ci

openshift-ci Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

@cajieh: all tests passed!

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.

@cajieh

cajieh commented Jun 17, 2026

Copy link
Copy Markdown
Contributor Author

/verified by @cajieh

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Jun 17, 2026
@openshift-ci-robot

Copy link
Copy Markdown
Contributor

@cajieh: This PR has been marked as verified by @cajieh.

Details

In response to this:

/verified by @cajieh

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.

@cajieh

cajieh commented Jun 17, 2026

Copy link
Copy Markdown
Contributor Author

/retest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. component/core Related to console core functionality component/sdk Related to console-plugin-sdk jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. plugin-api-changed Categorizes a PR as containing plugin API changes verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants