Change mapping of permission NOTIFICATIONS_READ to legacy role

[brat002]

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 to VIEWER 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 from EDITOR to VIEWER role.

Which issue(s) this PR closes

Checklist

• Unit, integration, and e2e (if applicable) tests updated
• Documentation added (or pr:no public docs PR label added if not required)
• Added the relevant release notes label (see labels prefixed w/ release:). These labels dictate how your PR will
  show up in the autogenerated release notes.

[CLAassistant]

All committers have signed the CLA.

[alexandr-ku-MA]

Guys, could you take a look?
@matiasb ?

[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).

[brat002]

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.

[brat002]

Added. I've found a block of settings with FEATURE_ prefix. I suppose the setting also may be considered as a FEATURE.

[xemekk]

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

[matiasb]

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?

[brat002]

I've added dynamic definition of Permission class based on feature toggle. I think this looks better then 5 If/else. @matiasb wdyt?

[brat002]

So, any suggestions, ideas, complaints? Can we merge it?

[matiasb]

To be sure, what happens with the other permissions when the setting is enabled? This seems like it could break if combined with an RBAC-based setup?
OTOH, what if permissions are added or changed? I think we would prefer a more general/reusable approach to avoid potential unexpected behaviors in the future (I still think allowing viewers to be on-call may make sense in some cases, but it would be nice to make the change as simple and future-proof as possible)

[alexandr-ku-MA]

To be sure, what happens with the other permissions when the setting is enabled? This seems like it could break if combined with an RBAC-based setup?

I don't see how the changes may break something. When FEATURE_ALLOW_VIEWERS_ON_CALL == false - previously existing logic is being used. Class Permissions doesn't have any modifications. ViewerOnCallPermissions simply redefines several permissions. Do I miss something?

[brat002]

@matiasb could you clarify please?

it could break if combined with an RBAC-based setup

There is no significant changes in a logic. Everything the code does is just an assignment of permission model on an init stage of a code. We still use Permissions class to define permissions. New class inherits Permissions and redefines only those ones, which affects a scope of 'Viewer role should be able to be OnCall'.

Obviously, this approach creates another area to consider when extending the permissions model, but I don't see a better way to do it. Of course, having a fully functional, configurable RBAC model in Grafana OnCall would make this PR unnecessary, but that might happen sometime in the future. We live in the present...
Please, give me know if you'd like to change something in my approach.

p.s. I resolved conflicts.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!