-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Fixed permission issue for Data Asset Header component #27967
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Rohit0301
wants to merge
5
commits into
main
Choose a base branch
from
fix-26866-1
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+186
−5
Open
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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) usesSPECIFIC_ALLOW_EDIT_ALL_DENY_RULESwhich sets EditTier/EditOwners/EditCertification to allow and EditAll to deny. SincegetPrioritizedEditPermissionnow returnspermissions[Operation.EditTier]directly (the key always exists), if the backend resolves EditTier astruedespite 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 fixto apply this suggestionThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if editALL is deny, other permission inherits this value, and other permission also get denied by default from backend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification! That makes sense — if EditAll is denied, the backend propagates that deny to all specific edit operations (including EditTier, EditOwners, EditCertification), so they all resolve to
falseregardless of any explicit allow rules. This means the test is correctly relying on backend policy resolution where deny always wins at the EditAll level.The finding was noting a potential risk: if
getPrioritizedEditPermissionreturns the rawpermissions[Operation.EditTier]value directly, the frontend behavior depends entirely on the backend correctly cascading the EditAll deny. Since that's guaranteed by the backend's policy engine, the test is sound and the concern is resolved.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gitar-bot please re-review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After re-reviewing, the original finding stands.
What
getPrioritizedEditPermissiondoes (PermissionsUtils.ts:127–131):What
SPECIFIC_ALLOW_EDIT_ALL_DENY_RULESproduces on the backend:Each operation is evaluated independently. OpenMetadata's deny-wins semantics apply per-operation, not across operations.
EditAll: denydoes not cascade to denyEditTier,EditOwners, orEditCertification. The backend will return{ EditTier: true, EditOwners: true, EditCertification: true, EditAll: false }for this user.What
getPrioritizedEditPermissionthen returns:Since
has(permissions, 'EditTier')istrue, it short-circuits and returnspermissions['EditTier']→true. The button is shown.The conflict: The test at lines 229–244 expects
not.toBeVisible(), but the implementation would make the button visible. These two cannot both be correct simultaneously.The resolution depends on the intended product behavior:
EditAll: denyshould suppress all specific edit buttons (deny EditAll means deny everything), thengetPrioritizedEditPermissionmust also gate onEditAll— e.g.,return permissions[fieldEditPermission] && permissions[Operation.EditAll]. The test would then be correct, but the function's current semantics (specific overrides general) would be inverted for the deny case.EditAll(the current function semantics), then the test assertion should betoBeVisible(), notnot.toBeVisible().This is a genuine inconsistency between the utility function's logic and the test's expectation.