Security and daily use - Slack
Scope: account and project
The Slack configuration lives in two scopes. The account holds the default used by every one of the subscriber's projects. A project inherits it automatically (the inherit from account mode), but for each event type it can also explicitly choose send with its own channel, or don't send - independently of whatever the rest of the account does. That lets you mute one noisy project without touching the configuration of the others.
There is also a third, platform scope, with no account attached. It only serves Dock's own internal-account projects; a subscriber never uses it and cannot even see it.
Who has access
The screen requires the project-management permission, held by the developer, admin and owner roles (and superdeveloper for internal accounts). It is the same matrix as editing the projects themselves: whoever can change monitoring settings can also change where its alerts go.
How the credential is stored
The bot token is encrypted in the database. The form never shows it in plain text - leaving the field blank on save means 'keep what is there', not 'clear it'. To actually remove the integration, turn the provider off rather than just emptying the token field.
Why the address isn't validated the way Mattermost's is
Slack does not accept an arbitrary address - the integration talks to Slack's own, fixed API using a token, so there is no field here that could be redirected into DockRay's internal network. The same caution that applies to Mattermost's webhook address applies here to the shape of the token instead.
Keeping the team from being flooded
Five event types mean five independent switches and five potentially different channels. Split them up instead of sending everything to one general channel - it is worth keeping availability incidents apart from performance notices so the former don't get lost among the latter. A sudden error spike (error-spike) has its own safeguard, independent of the Slack setup: it is checked every 15 minutes but sent for the same project at most once every few hours, so the same channel will not get a string of identical alerts in one afternoon.
Rotating the token
A suspicion that a token has leaked is reason enough to revoke it. In Slack: OAuth & Permissions → Revoke, or reinstall the app in the workspace, which issues a new Bot User OAuth Token. Paste the new token into DockRay and send a test - only a successful test confirms that the old token really stopped working and the new one has access to the right channels.
When someone leaves the team
The bot token does not belong to any one person - it belongs to the Slack app, not a login. Someone leaving the team does not invalidate it by itself. If that person had access to the Slack admin panel or to DockRay itself and could have seen the token, treat it as a suspected leak and rotate it the way described above.