Add a slash command to subscribe new AWS SNS topics to Mattermost channels

[jasonblais]

Only users listed under AllowedUserIds should be allowed to execute this command

[elyscape]

This should probably also allow different topics to be sent to different channels.

[george-cionca]

I would be interested in starting to work on this ticket.

Before starting to work on this ticket, I have a few questions:

1. Is it possible for this plugin to be enabled for multiple channels? This will represent my first contribution to Mattermost and I am not completely accustomed to the business logic, but the README file of this project states:

   Set the channel to send notifications to, specified in the format teamname,channelname. If the specified channel does not exist, the plugin will create the channel for you.

   Taking into consideration the previous explanation, is it required for the new slash command to handle multiple channel names and associated SNS topics? As an example, I'm referring to the next possible format for the command:

   /addSNSTopics (channelName1, [snsTopicName1, snsTopicName2, ...]), (channelName2, [snsTopicName1, snsTopicName2, ...]), etc.

   Or, is it required to have just a list of SNS topics to be added to the channel for which the plugin has been enabled? For example:

   /addSNSTopics snsTopicName1, snsTopicName2, etc.

2. In the description of this ticket is mentioned that:

   Only users listed under AllowedUserIds should be allowed to execute this command

   Does this refer to point 3 from the README file? Point 3 from the README file states:

   Set authorized users who can accept AWS SNS subscriptions. Must be a comma-separated list of user ID's.

3. I haven't noticed any tests for this plugin. I would like to know what testing approaches have been used when this plugin was developed?

   As for manual testing, I see that in the second section of the README file there is an explanation on how to configure AWS (CloudWatch and SNS). The free tier period from my AWS account has expired, but I plan on using LocalStack: https://github.com/localstack/localstack which provides the capability of starting AWS services locally as Docker containers. Of course, it will not replicate all the capabilities of AWS but I expect it to be sufficient for basic operations such as creating a CloudWatch alarm for an EC2 instance and creating an SNS subscription.

   Please let me know if previously there have been other approaches used to test the functionalities of this plugin.

---

For the time being, I think the previous questions should add enough context to allow me to start the work on this ticket. Thanks.

[jasonblais]

cc @mickmister @jfrerich

[mickmister]

@george-cionca

Is it possible for this plugin to be enabled for multiple channels?

Plugins are automatically enabled throughout the server. So they are enabled for all channels.

The way I see this feature is to run the following command in a given channel in which you want to receive notifications. This is most other plugins accomplish this:
/sns subscribe (topic1) (topic2)

It might be better to only allow one topic at a time, to have a more fluid error-handling experience. Also we should support topic name and full ARN for the args.

---

In the description of this ticket is mentioned that:

Only users listed under AllowedUserIds should be allowed to execute this command

Does this refer to point 3 from the README file? Point 3 from the README file states:

Set authorized users who can accept AWS SNS subscriptions. Must be a comma-separated list of user ID's.

Yes, it is a config value set in the system console. It can be accessed through p.getConfiguration().AllowedUserIds.

---

I would like to know what testing approaches have been used when this plugin was developed?

The package structure would likely need to be refactored, so we can support mocking of interfaces in separate packages. There are examples of this in https://github.com/mattermost/mattermost-plugin-mscalendar .

---

I plan on using LocalStack: localstack/localstack which provides the capability of starting AWS services locally as Docker containers. Of course, it will not replicate all the capabilities of AWS but I expect it to be sufficient for basic operations such as creating a CloudWatch alarm for an EC2 instance and creating an SNS subscription.

Fantastic! We would certainly welcome a PR with a docker-compose.yml file configured to spin up the necessary container(s) 👍

---

Thanks for your great questions and thanks for your interest in contributing @george-cionca!! You're welcome to join our community server and join the channel for this project to work more closely with the team.

[jfrerich]

Thanks for your interest and questions, @george-cionca! Do you have any additional questions or need any help getting started?

[george-cionca]

Thanks @mickmister and @jfrerich.

Sorry for the late reply. I was a bit busy in the past weeks and didn't have the chance to work on this ticket.

I plan to get started in the upcoming days. I will come back with further updates once I start to work on it.