-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
UI: Update resultant-acl banner #25256
Conversation
CI Results: |
Build Results: |
} | ||
const namespace = this.baseNs; | ||
const allowed = | ||
Object.keys(this.globPaths).any((k) => k.startsWith(namespace)) || |
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.
For someone not super familiar with this response, could you maybe add a comment with an example of glob vs exact paths? Especially since the API doc are 🙃 in information for this endpoint. Found this stackoverflow with someones examples to help me visual it.
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.
I think the best example is in the test file
I'd love to make this service glimmer + typescript, but since this change will be backported that will have to be a follow on
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.
Nice work. And a really thoughtful approach to the issue. One request, but non-blocking.
* Request resultant-acl only from users root namespace * Update permissions adapter to always call resultant-acl at users root, with test * Update resultant-acl to accept failType * Update permissions service to set permissionsBanner based on resultant-acl contents * wire it up * add changelog * cleanup unused adapter changes * use getter for shared namespace logic
This PR updates when the resultant-acl banner is shown to a user.
Before, we were always calling
resultant-acl
at the current namespace. This typically would fail when the user is accessing a child namespace that they have access to, unless the administrator specifically gave them read access to the resultant-acl path within that namespace. This is a subpar experience for both users and administrators.With this change:
ns1
, my resultant-acl call will always be made to namespacens1
regardless of the namespace I'm currently accessingWhen accessing a namespace that is not in your policy:
When logged in with a user that does not have the default policy attached