Open brat002 opened 2 months ago
Guys, could you take a look? @matiasb ?
Hey,
I see your point. But if you allow Viewers
to receive notifications, I guess you will also need them to act on alert groups (requiring alert groups write perm), and/or allow them to setup their notification policies (user settings write), right? So the main decision on our side would be if we should allow Viewers to be on-call, that AFAICT was discarded at some point (but it may make sense to have a global project setting enabling this? eg. ALLOW_VIEWERS_ON_CALL
).
I see your point. But if you allow
Viewers
to receive notifications, I guess you will also need them to act on alert groups (requiring alert groups write perm), and/or allow them to setup their notification policies (user settings write), right? So the main decision on our side would be if we should allow Viewers to be on-call, that AFAICT was discarded at some point (but it may make sense to have a global project setting enabling this? eg.ALLOW_VIEWERS_ON_CALL
).
The reasons make sense, although we use Grafana oncall mostly as an engine for Schedules. None of actual actions are expected from users.
I think adding ALLOW_VIEWERS_ON_CALL
is a good tradeoff. If so, I'll add the changes.
Added. I've found a block of settings with FEATURE_ prefix. I suppose the setting also may be considered as a FEATURE.
We've also encountered a problem here and moving users to editors only to let them be part of schedule isn't an option. Would love to have this merged
The reasons make sense, although we use Grafana oncall mostly as an engine for Schedules. None of actual actions are expected from users.
Ok, but I think if we have this toggle to enable Viewers to be on-call, we should allow them to perform all on-call related actions (so I would expect them to have the same perms as the OnCaller role we have defined), to have a more reusable/generally useful approach, makes sense?
I've added dynamic definition of Permission class based on feature toggle. I think this looks better then 5 If/else. @matiasb wdyt?
So, any suggestions, ideas, complaints? Can we merge it?
The problem the PR solves is a user must have
EDITOR
role in Grafana to be included into a Schedule.If we compare other
_READ
level privileges with their legacy roles, they are mapped toVIEWER
role (except API keys read).In short, the main idea of this change is to avoid granting a user
EDITOR
role in a whole organization only because a user should be a part of some Schedule.What this PR does
This PR changes a mapping of
NOTIFICATIONS_READ
permission fromEDITOR
toVIEWER
role.Which issue(s) this PR closes
Checklist
pr:no public docs
PR label added if not required)release:
). These labels dictate how your PR will show up in the autogenerated release notes.