-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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
Access control: expose permissions to the frontend #32954
Access control: expose permissions to the frontend #32954
Conversation
90bba80
to
9eff344
Compare
…se-permissions-to-frontend
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.
Looks good! Left a few minor comments to consider.
@@ -46,6 +46,7 @@ export interface FeatureToggles { | |||
live: boolean; | |||
ngalert: boolean; | |||
panelLibrary: boolean; | |||
accesscontrol: boolean; |
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.
accesscontrol: boolean; | |
accessControl: boolean; |
I think we'd be consistent with casing. Also shouldn't it be down under the enterprise feature toggles?
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.
Hm, maybe. But right now we have feature toggle called accesscontrol
. So I'd preffer to fix it in another PR.
@@ -57,6 +57,7 @@ export class GrafanaBootConfig implements GrafanaConfig { | |||
ngalert: false, | |||
panelLibrary: false, | |||
reportVariables: false, | |||
accesscontrol: false, |
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.
accesscontrol: false, | |
accessControl: false, |
* action: { scope: scope } | ||
* } | ||
*/ | ||
export type UserPermission = { |
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.
Should this be in the "app/types" instead?
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.
Yes, makes sense to move.
return !!( | ||
this.user.permissions && | ||
this.user.permissions[action] && | ||
(scope ? this.user.permissions[action][scope] : true) | ||
); |
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.
return !!( | |
this.user.permissions && | |
this.user.permissions[action] && | |
(scope ? this.user.permissions[action][scope] : true) | |
); | |
return !!(this.user.permissions?.[action] && (scope ? this.user.permissions[action][scope] : true)); |
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.
This is how prettier formats this.
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.
This is not about formatting, you can remove an extra this.user.permissions
check with the optional chaining operator.
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.
Got it. Did it before, but had some linter errors. Will try again.
🎉 🕺 |
This PR exposes permissions assigned to user to the frontend inside a
bootData
object. Then permissions can be checked with theContextSrv
(hasPermission()
method) in the runtime. Then we can change a way how we render components depending on required access (render only if user have access, show info banner, disable action buttons, etc).