[2.0] Partially addresses #34954: expand nested glossary search matches in the term picker (UI only)

[anuj-kumary]

Describe your changes:

Partially addresses #34954 — UI half only. The backend half is handled separately on main by @sonikashah and will be cherry-picked to 2.0.

Searching in the glossary term picker didn't let users select a term nested under other terms. There were two causes, one in the UI and one in the backend; this PR carries only the UI one.

Matches stayed collapsed. The search response already carries the full path to each match, but TreeAsyncSelectList's onSearch expanded only the top-level results (the glossaries). A match under "Customer" sat collapsed until the user expanded every level by hand.

• Fix: expand every level of the (filtered) results using the existing findExpandableKeysForArray helper from GlossaryPureUtils. Search still makes a single API call.

This change is purely client-side: it only changes what the component does with the response it already receives, so it needs no backend change to be correct and can merge independently.

Not in this PR (backend, tracked separately): with getHierarchy=true and more matches than one page, buildHierarchyQuery ranks matches and their ancestor terms together, the ancestors get cut, and buildGlossaryTermSearchHierarchy then drops every match — each glossary comes back as children: []. Until that lands, the many-matches case stays broken regardless of this PR; the common few-matches case is fixed here.

Screen.Recording.2026-10-08.at.8.45.05.PM.mov

Type of change:

• Bug fix

High-level design:

N/A — small change.

Tests:

Use cases covered

• Searching a term nested 5 levels deep shows the full path, already expanded, and the term can be selected directly.
• A search that matches only a few terms (the common case) now renders every level expanded instead of collapsed.

Unit tests

• TreeAsyncSelectList.test.tsx: new test. It searches, returns Business › Customer › Churn, and asserts the level-3 node renders. It fails without the fix and passes with it.

Backend integration tests

• Not applicable (no backend changes in this PR).

Ingestion integration tests

• Not applicable (no ingestion changes).

Manual testing performed

Seeded a local 2.0.5 server (Elasticsearch 9.3) with the sample data plus 25 glossaries × 27 approved terms nested 5 levels deep, and ran the picker's request (size=25&getHierarchy=true):

Search	Before	After
SalesMetrics (2 matches)	full paths, but collapsed in the picker	full paths, all levels expanded

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue above.
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: not applicable.
• For UI changes: I attached a screen recording and/or screenshots above.
• I have added tests (unit / integration / Playwright as applicable) and listed them above.

🤖 Generated with Claude Code

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	67.77% (82065/121084)	52.49% (50582/96365)	53.48% (15107/28243)

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · Expanding every nested search result in the term picker could render large hierarchies at once and make selection harder to navigate.

Glossary term picker search now expands every level of matching results so nested terms are visible and selectable, and the backend backfills missing ancestor terms so glossaries no longer come back empty when a search matches more terms than one page. The ancestor backfill now respects the Approved-status filter, addressing the resolved finding. No open issues found.

✅ 1 closed

✅ Bug: Ancestor backfill skips the entityStatus=Approved filter

📄 openmetadata-service/src/main/java/org/openmetadata/service/search/elasticsearch/ElasticSearchSearchManager.java:1716-1730 📄 openmetadata-service/src/main/java/org/openmetadata/service/search/opensearch/OpenSearchSearchManager.java:1798-1812
buildHierarchyQuery limits both the matches and the ancestors it pulls in to entityStatus: Approved (lines ~1556 and ~1600). The new fetchTermsByFqn runs a bare terms query on fullyQualifiedName with no status filter. Here's how that goes wrong: an Approved term sits under a Draft, In Review or Rejected parent. Before this change the parent was left out and the child was dropped. Now the non-approved parent is fetched and added to the tree, so it shows up in the glossary picker. When isParentSelectable is set, users can tag assets with that unapproved term. Fix: AND the same Approved filter into the backfill query. Optionally, drop matches whose ancestors are not all approved.

Verification

Rules No rules evaluated

Functional validation Not enabled

Set up

Auto-approval Not enabled

Set up

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud