Skip to content

Fixed permission issue for Data Asset Header component#27967

Open
Rohit0301 wants to merge 5 commits intomainfrom
fix-26866-1
Open

Fixed permission issue for Data Asset Header component#27967
Rohit0301 wants to merge 5 commits intomainfrom
fix-26866-1

Conversation

@Rohit0301
Copy link
Copy Markdown
Contributor

@Rohit0301 Rohit0301 commented May 7, 2026

Describe your changes:

There was a case where EditALL permission is allowed and EditTier permission is deny, but it still the edit icon is visible for tier on UI, so i have first check the EditTier condition then check the EditAll permission.

Fixes #26866

Screen.Recording.2026-05-07.at.7.19.15.PM.mov
Screen.Recording.2026-05-07.at.7.17.45.PM.mov

I worked on ... because ...

Type of change:

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

High-level design:

N/A — small change.

Tests:

Use cases covered

Unit tests

Backend integration tests

Ingestion integration tests

Playwright (UI) tests

Manual testing performed

UI screen recording / screenshots:

Not applicable.

Checklist:

  • I have read the CONTRIBUTING document.
  • My PR title is Fixes <issue-number>: <short explanation>
  • My PR is linked to a GitHub issue via Fixes #<issue-number> above.
  • 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.
  • 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.

Summary by Gitar

  • New functionality:
    • Integrated useDataAccessRequest in DataAssetsHeader to check for existing data access requests.
    • Added a disabled state to the request data access button when a request already exists.
  • Refactor:
    • Streamlined DataAssetsHeader by passing refetchExistingDar to component helpers for dynamic updates.

This will update automatically on new commits.

@Rohit0301 Rohit0301 self-assigned this May 7, 2026
@Rohit0301 Rohit0301 requested a review from a team as a code owner May 7, 2026 14:00
@Rohit0301 Rohit0301 added safe to test Add this label to run secure Github workflows on PRs To release Will cherry-pick this PR into the release branch labels May 7, 2026
shah-harshit
shah-harshit previously approved these changes May 7, 2026
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 7, 2026

Jest test Coverage

UI tests summary

Lines Statements Branches Functions
Coverage: 62%
62.5% (63202/101116) 42.97% (34249/79688) 45.87% (10088/21991)

Comment on lines +229 to +243
headerPermTest(
'EditTier, EditOwners, EditCertification allowed but EditAll denied – edit buttons not visible',
async ({ specificEditsPage }) => {
await headerPermTable.visitEntityPage(specificEditsPage);

await expect(
specificEditsPage.getByTestId('edit-tier')
).not.toBeVisible();
await expect(
specificEditsPage.getByTestId('edit-owner')
).not.toBeVisible();
await expect(
specificEditsPage.getByTestId('edit-certification')
).not.toBeVisible();
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Edge Case: E2E test expects specific-allow + EditAll-deny to hide buttons

The test 'EditTier, EditOwners, EditCertification allowed but EditAll denied – edit buttons not visible' (line 229-244) uses SPECIFIC_ALLOW_EDIT_ALL_DENY_RULES which sets EditTier/EditOwners/EditCertification to allow and EditAll to deny. Since getPrioritizedEditPermission now returns permissions[Operation.EditTier] directly (the key always exists), if the backend resolves EditTier as true despite EditAll being denied, the button would be visible and the test would fail.

This test passing depends on the backend's policy resolution cascading the EditAll deny to specific operations (i.e., deny always wins). If that's the intended backend behavior, this is fine — but it means this test is actually testing backend policy resolution rather than the frontend logic change. Please confirm the test passes in CI.

Was this helpful? React with 👍 / 👎 | Reply gitar fix to apply this suggestion

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 7, 2026

🟡 Playwright Results — all passed (14 flaky)

✅ 4016 passed · ❌ 0 failed · 🟡 14 flaky · ⏭️ 86 skipped

Shard Passed Failed Flaky Skipped
🟡 Shard 1 297 0 2 4
🟡 Shard 2 751 0 4 8
🟡 Shard 3 757 0 4 7
🟡 Shard 4 789 0 1 18
✅ Shard 5 687 0 0 41
🟡 Shard 6 735 0 3 8
🟡 14 flaky test(s) (passed on retry)
  • Features/DataAssetRulesDisabled.spec.ts › Database Schema (shard 1, 1 retry)
  • Flow/SearchRBAC.spec.ts › User without permission (shard 1, 1 retry)
  • Features/ActivityAPI.spec.ts › Activity event shows the actor who made the change (shard 2, 1 retry)
  • Features/BulkEditEntity.spec.ts › Glossary (shard 2, 1 retry)
  • Features/DomainFilterQueryFilter.spec.ts › 3-level domain hierarchy: SubSubDomain assets visible when SubDomain selected (shard 2, 1 retry)
  • Features/Glossary/GlossaryWorkflow.spec.ts › should start term as Draft when glossary has reviewers (shard 2, 2 retries)
  • Features/RTL.spec.ts › Verify Following widget functionality (shard 3, 1 retry)
  • Features/UserProfileOnlineStatus.spec.ts › Should show "Active recently" for users active within last hour (shard 3, 1 retry)
  • Features/UserProfileOnlineStatus.spec.ts › Should not show online status for inactive users (shard 3, 1 retry)
  • Flow/ObservabilityAlerts.spec.ts › Alert operations for a user with and without permissions (shard 3, 2 retries)
  • Pages/DataContractInheritance.spec.ts › Delete Asset Contract - Falls back to showing inherited contract from Data Product (shard 4, 1 retry)
  • Pages/Glossary.spec.ts › Column dropdown drag-and-drop functionality for Glossary Terms table (shard 6, 1 retry)
  • Pages/Lineage/LineageFilters.spec.ts › Verify lineage schema filter selection (shard 6, 1 retry)
  • Pages/ODCSImportExportPermissions.spec.ts › User with EditAll can export ODCS contract (shard 6, 1 retry)

📦 Download artifacts

How to debug locally
# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace

@gitar-bot
Copy link
Copy Markdown

gitar-bot Bot commented May 8, 2026

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Updates the Data Asset Header component to correctly prioritize EditTier permission checks over EditAll, fixing the visibility of the edit icon. Ensure the updated E2E test accurately validates the specific-allow and EditAll-deny rule combination.

💡 Edge Case: E2E test expects specific-allow + EditAll-deny to hide buttons

📄 openmetadata-ui/src/main/resources/ui/playwright/e2e/Features/Permissions/EntityPermissions.spec.ts:229-243

The test 'EditTier, EditOwners, EditCertification allowed but EditAll denied – edit buttons not visible' (line 229-244) uses SPECIFIC_ALLOW_EDIT_ALL_DENY_RULES which sets EditTier/EditOwners/EditCertification to allow and EditAll to deny. Since getPrioritizedEditPermission now returns permissions[Operation.EditTier] directly (the key always exists), if the backend resolves EditTier as true despite EditAll being denied, the button would be visible and the test would fail.

This test passing depends on the backend's policy resolution cascading the EditAll deny to specific operations (i.e., deny always wins). If that's the intended backend behavior, this is fine — but it means this test is actually testing backend policy resolution rather than the frontend logic change. Please confirm the test passes in CI.

🤖 Prompt for agents
Code Review: Updates the Data Asset Header component to correctly prioritize EditTier permission checks over EditAll, fixing the visibility of the edit icon. Ensure the updated E2E test accurately validates the specific-allow and EditAll-deny rule combination.

1. 💡 Edge Case: E2E test expects specific-allow + EditAll-deny to hide buttons
   Files: openmetadata-ui/src/main/resources/ui/playwright/e2e/Features/Permissions/EntityPermissions.spec.ts:229-243

   The test `'EditTier, EditOwners, EditCertification allowed but EditAll denied – edit buttons not visible'` (line 229-244) uses `SPECIFIC_ALLOW_EDIT_ALL_DENY_RULES` which sets EditTier/EditOwners/EditCertification to allow and EditAll to deny. Since `getPrioritizedEditPermission` now returns `permissions[Operation.EditTier]` directly (the key always exists), if the backend resolves EditTier as `true` despite EditAll being denied, the button would be visible and the test would fail.
   
   This test passing depends on the backend's policy resolution cascading the EditAll deny to specific operations (i.e., deny always wins). If that's the intended backend behavior, this is fine — but it means this test is actually testing backend policy resolution rather than the frontend logic change. Please confirm the test passes in CI.

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact
gitar display:verbose         

Was this helpful? React with 👍 / 👎 | Gitar

@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud Bot commented May 8, 2026

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

Labels

safe to test Add this label to run secure Github workflows on PRs To release Will cherry-pick this PR into the release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tier change option visible without edit permission – UI gets stuck

2 participants