Implement Alert Management permission levels
From @sarahwaldner !30024 (comment 330273099)
I agree with how @tristan.read outlined the permissions for this feature. We need two states for that page, as @ameliabauerly outlined:
- Maintainers & owners can enable alerting, so they can see the button to enable it
- Developers & lower can not enable alerting, so the button is hidden for them
- Developers & higher can read alerts & edit status of alerts
We may need to restrict what reporters can see. I agree that alerts may likely contain sensitive information. Let's copy the permissions used for Vulnerabilities for the actions that each role can take for alerts.
In addition, we should ensure the following behaviour:
- Anyone who can read alerts (Developer & higher) can see Alerts in the sidebar and view the
<project>/-/alert_management
route. - Anyone who cannot read alerts (Reporter & below) cannot see Alerts in the sidebar and the
<project>/-/alert_management
route displays a 404.
Permissions for each role do not change based on the tier.
Permissions checklist!
-
Roles: Ensure enable/read/update operations are tied to the correct roles - !31262 (merged) -
Endpoint access: <project>/-/alert_management
- !31262 (merged) -
Endpoint access: /graphql
-> read alerts - !30140 (merged) -
Endpoint access: /graphql
-> mutate alerts - !30576 (merged) -
Endpoint access: <project>/-/services/alerts/edit
- protected as part of services under:admin_project
permission -
Visibility: 'Alerts' menubar option - !29775 (merged) -
Visibility: setup button for 'Alerts endpoint' integration from view for <project>/-/alert_management
- !30024 (merged), !31260 (merged) -
Visibility: 'Alerts endpoint' integration page - protected as part of services under :admin_project
permission
Edited by Sarah Yasonik