We spend some time today with @zj thinking about different approaches for configuring Mattermost.
This comment tries to describe my proposal and describe it pros and cons.
We looked into a way how we can integrate Mattermost with Slash commands,
as this seems like a something that is easiest to implement and proceed.
Proposal
Idea is to extend Mattermost with global configuration of slash commands
Slash commands would then be available for all teams and on all channels.
We would assume convention of naming teams and channels.
Teams should be named as a group and channels should be named as a project names.
We would allow to put a overrides to change integration of GitLab with channel and project.
Currently, Mattermost allows to add slash commands only on team-basis.
The slash commands can be added with API,
but in order to access API it requires us to do a lot of additional work.
This also makes it quite hard to ship a new slash commands,
because then we need to migrate all teams to have support for new commands.
This allows us to automatically and out of box ship any number of pre-defined slash commands and easily extend them on GitLab,
This allows us to have a simple convention over configuration:
We would assume that people would create a group name that would match a Mattermost team,
We would assume that people would create a project that would match a Mattermost channel,
We could easily allow to specify that this project is connected to different team,
This proposal assumes that administrator uses one Mattermost installation per GitLab installation,
This allows us to automatically match usernames, and use the permissions of users when evaluating slash commands on GitLab,
This solves the authorization problem, because we assume that Mattermost uses only GitLab OAuth, and we assume that we can match the user on Mattermost to the user on GitLab, allowing us to execute commands on behalf of the user,
This makes the configuration of Mattermost for a project to be no-configuration at all. When Administrator would configure Mattermost for a GitLab installation, the Mattermost Service would be automatically enabled and would have the assumptions for team and channel as defined above,
This allows us to have very simple overrides for Mattermost Service: Team name and Channel name, to define different team and channel allow to use slash commands on different channels,
This allows us to easily add a number of other slash commands automatically, by adding them to Omnibus generated Mattermost configuration,
This allows us to use the same implementation of Slash commands with Slack,
The slash commands could be configured as Slack app and used for GitLab.com,
Cons
This assumes that only Slash commands are used, this doesn't describe the Bot integration,
Using slash commands with Slack can be troubling due to security issues of matching the Slack user with a GitLab user,
GitLab: mid-size work is required on GitLab to: use predefined slash commands token, rework the integrations to be a Mattermost service of project, extend slash commands to support additional syntax
Since this is very simple thing to do and most of things are already done this seems like a simplest MVP to have it supported.
Ill extent this post a bit later, but just to mention it:
I like the option to create an admin account through the Mattermost CLI, with known credentials. This way we could leverage all APIs Mattermost exposes. So if we'd want to create a Mattermost Team per GitLab group we have credentials in place already and won't have to solve this problem again.
We would assume that people would create a group name that would match a Mattermost team,
I'm not sure about nomenclature, but does Mattermost use "team" the same way Slack does? i.e. it's the name of the instance like gitlab.slack.com? If so, wouldn't we expect single-tenant installs of GitLab to have multiple GitLab groups for the same Mattermost team?
At any rate, if this is needed, can we enforce that this is true? Do we create Mattermost teams automatically as part of installation?
We would assume that people would create a project that would match a Mattermost channel
This is a great simplification to get us started, but in practice we know this isn't true. Can we start by creating those channels for them rather than assuming they've created matching named channels?
For the demo, I'm fine with this being the extent of it, but I'd like to know that we have a path to supporting more realistic flows.
We could easily allow to specify that this project is connected to different team,
I'm not sure what this is for. Following the above, wouldn't you want to at most map a GitLab group to a different Mattermost team? Not individual projects to different teams? Maybe I'm missing something.
If so, wouldn't we expect single-tenant installs of GitLab to have multiple GitLab groups for the same Mattermost team?
I think this only makes sense for smaller instances, all the others not really. If you are really small, why would you need more groups?
Can we start by creating those channels for them rather than assuming they've created matching named channels?
Either through the API or the Mattermost CLI this should be possible. Lets first configure the slash commands first though, and work our way up to teams and channels :)
Now to further expand my proposal:
Proposal
I'd love to have full API access to Mattermost as it would simplify a lot of further integration actions, like creating teams, adding members to a team because they became member on the GL group etc. To achieve this we need either:
Let the admin OAuth with GitLab so GitLab has credentials to perform API requests with
Create a fake admin user through the Mattermost CLI so we have credentials
My preference goes to number 2, as that is way more magical and doesn't need a guide for the admin to set it up. Once this is done we have an admin username and password combination to perform requests.
Pros
The API exposes much more functionality to us for future iterations
If a new member is in the GL group we could add them to the Team too
Anything which can be done through the UI we can do through the API now
No changes in either omnibus, nor Mattermost
Especially now MM might moves to a bimonthly release we stay a little more agile
Updating the slash commands is just a button click, or a migration
No assumptions have to be made anymore, we could enforce them
I've been thinking about this a bit more, also talked with @ayufan on Slack, and come to the realisation Kamils idea is better at this point. Also because its less of a stretch to be done within a week. Later we could always implement the API support and build on it.
At any rate, if this is needed, can we enforce that this is true? Do we create Mattermost teams automatically as part of installation?
It's hard, because we don't really control the group/channel creation on Mattermost.
This is a great simplification to get us started, but in practice we know this isn't true. Can we start by creating those channels for them rather than assuming they've created matching named channels?
Yes I know. That is what I meant by allowing to have override where you could go to your project settings and connect your project to channel.
Maybe we can do that from Mattermost, to connect group/channel with project, but on the other hand this is one time operation so I'm not sure if this makes sense.