Design: Slack application settings by roles

The purpose of this issue is to define the roles and usage patterns of GitLab Slack users. Currently an organisation links a single Slack workspace to a GitLab account which can then be used at different levels (instance, group, project) and administered and consumed by different GitLab user roles (e.g. Reporter, Developer, Owner, etc.).

The questions that need to be answered are:

  1. Who are these personas?
  2. What set or subset of settings should be available for each persona type?
  3. Where should these settings live (e.g. in a GitLab project or group, or the client application, or both)?

Note: As an MVC it maybe easier to expose settings for the Developer persona within the Slack app, however we want to be able to configure and manage the integration from GitLab first.

Customers get a bit frustrated having to do things differently for every integration, having to go into each app separately.

Personas and Roles

GitLabs personas that use integrations can be broken down into:

  • Sidney (Systems Administrator) this is someone that is in charge of setting up the integration and then makes it available for the rest of their organization. This persona is commonly a group or project Owner, which means they have access a group/project Settings.
  • Sasha (Software Developer) this persona is more of the "user" or "consumer" of an integration. Their role can range from Reporter to Developer, which means that they don't have access to a group or project's Settings.

Sidney (Systems Administrator)

  • Manage integration at the instance / group / project level
  • Manage which GitLab users have access
  • Manage application in the Slack workspace
  • Manage channel notification
  • Manage DM notifications
  • Manage linked GitLab projects

Sasha (Software Developer)

Edited by Libor Vanc