Refactor permission issue for ontology data mode

[anuj-kumary]

Describe your changes:

Fixed a permission issue in data mode when clicking on a term.
In data mode, nodes were being created using id: fqn (the FQN string) instead of a UUID, while the function expects a UUID. As a result, the backend was unable to resolve the entity and returned empty permissions, causing a "no permission" error even for admins.

Screen.Recording.2026-04-14.at.8.43.54.AM.mov

Type of change:

• Bug fix
• Improvement
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	63.86% (59795/93626)	43.63% (31326/71791)	46.72% (9415/20151)

[gitar-bot]

Code Review 👍 Approved with suggestions 2 resolved / 4 findings

Refactors the ontology data permission logic and addresses stale UI issues caused by missing stats change triggers. Consider replacing the silent catch block with proper error logging and switching to a waiting visibility check for canvas nodes.

💡 Quality: Silent catch block hides graph update errors

📄 openmetadata-ui/src/main/resources/ui/src/components/OntologyExplorer/hooks/useOntologyGraph.ts:1358-1359

The empty catch { // ignore } block at line 1358 in useOntologyGraph.ts silently swallows all errors from graph.updateNodeData / graph.updateEdgeData. While the intent is to tolerate transient mismatches, this makes debugging graph rendering issues very difficult. Consider logging at debug level or at least documenting which specific errors are expected.

💡 Quality: rightClickCanvasToFindNode uses non-waiting isVisible() check

📄 openmetadata-ui/src/main/resources/ui/playwright/e2e/Features/OntologyExplorer.spec.ts:708-714

In rightClickCanvasToFindNode, page.getByTestId('node-context-menu').isVisible() is a synchronous, non-auto-waiting check. Unlike expect(...).toBeVisible() or .waitFor(), it returns immediately — if the context menu takes even a few frames to render after right-click, the check returns false and the loop moves on to the next offset.

Contrast with clickCanvasAndWaitForPanel which correctly uses .waitFor({ state: 'visible', timeout: 1500 }). The same pattern should be used here for consistency and reliability.

Suggested fix

const menuVisible = await page
  .getByTestId('node-context-menu')
  .waitFor({ state: 'visible', timeout: 1500 })
  .then(() => true)
  .catch(() => false);

if (menuVisible) {
  return true;
}

✅ 2 resolved

✅ Edge Case: Test clicks at pixel (0.5, 0.5) — unlikely to hit a node

📄 openmetadata-ui/src/main/resources/ui/playwright/e2e/Features/OntologyExplorer.spec.ts:535
The test clickCanvasAndWaitForPanel(page, 0.5, 0.5) clicks at coordinates (0.5, 0.5) pixels from the canvas top-left origin. This is essentially the top-left corner of the canvas, which is very unlikely to contain a rendered term node (especially after fit-view centers the graph). If no node is hit, the panel won't appear and the toBeVisible() assertion will fail, making this test flaky.

Consider using the canvas bounding box dimensions to compute a center-ish click position, or use a retry loop with multiple positions to find a node.

✅ Bug: onStatsChange never called when stats become empty → stale UI

📄 openmetadata-ui/src/main/resources/ui/src/components/OntologyExplorer/OntologyExplorer.tsx:2126-2130
The useEffect guarding onStatsChange (line 2127) only fires when statsItems.length > 0. If the user changes filters such that no nodes remain, statsItems becomes [] but the parent OntologyExplorerPage is never notified. The page continues displaying the previous stats, which is misleading.

Since statsItems is derived from graphDataToShow and can legitimately be empty after filter changes, the guard should be removed so the parent always receives the current value.

🤖 Prompt for agents

Code Review: Refactors the ontology data permission logic and addresses stale UI issues caused by missing stats change triggers. Consider replacing the silent catch block with proper error logging and switching to a waiting visibility check for canvas nodes.

1. 💡 Quality: Silent catch block hides graph update errors
   Files: openmetadata-ui/src/main/resources/ui/src/components/OntologyExplorer/hooks/useOntologyGraph.ts:1358-1359

   The empty `catch { // ignore }` block at line 1358 in `useOntologyGraph.ts` silently swallows all errors from `graph.updateNodeData` / `graph.updateEdgeData`. While the intent is to tolerate transient mismatches, this makes debugging graph rendering issues very difficult. Consider logging at debug level or at least documenting which specific errors are expected.

2. 💡 Quality: rightClickCanvasToFindNode uses non-waiting isVisible() check
   Files: openmetadata-ui/src/main/resources/ui/playwright/e2e/Features/OntologyExplorer.spec.ts:708-714

   In `rightClickCanvasToFindNode`, `page.getByTestId('node-context-menu').isVisible()` is a synchronous, non-auto-waiting check. Unlike `expect(...).toBeVisible()` or `.waitFor()`, it returns immediately — if the context menu takes even a few frames to render after right-click, the check returns `false` and the loop moves on to the next offset.
   
   Contrast with `clickCanvasAndWaitForPanel` which correctly uses `.waitFor({ state: 'visible', timeout: 1500 })`. The same pattern should be used here for consistency and reliability.

   Suggested fix:
   const menuVisible = await page
     .getByTestId('node-context-menu')
     .waitFor({ state: 'visible', timeout: 1500 })
     .then(() => true)
     .catch(() => false);
   
   if (menuVisible) {
     return true;
   }

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
1098 New issues
0 Accepted issues

Measures
14 Security Hotspots
0.0% Coverage on New Code
3.8% Duplication on New Code

See analysis details on SonarQube Cloud