Integrating Stride & Slack or multiple different Stride Instances

Christian Reichert (resolution)
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 21, 2018

Hi Team,

I'd like to share our free App (Joint Rooms for Stride) with you - as I have been asked about an integration between Slack & Stride many times.

We originally developed the App due to our own needs where we have people we need to collaborate in different Slack Teams. 

Essentially our App can link channels together ... so I can for example link the #dev channel in our slack to the Development one in our Stride instance and everyone sees all the posts.

This, even though it wasn't the original intention, also works to link channels across two Stride Instances for example ... which is great for a Atlassian Partner to collaborate with some of their customers where everyone has a separate Stride Instance.

The App is pretty flexible, so can easily have many 1:1 connections across different systems but you can also link the same room across multiple instances/systems regardless of Slack/Stride or any combination.

If this fills a Need for you, give the App a spin - https://marketplace.atlassian.com/apps/1218548/joint-rooms?hosting=cloud&tab=overview

We would appreciate your Feedback here, to see what you make of it.

Thanks!


Cheers,
Christian

1 comment

Ankit Agarwal July 3, 2018

Hey, 

The App looks interesting, but is asking for a lot of permission hinting that the app may have access to private data of the company which can be lead to misused. We would to expose the data of a single channel, not the entire workspace. 

Please let me know if I have understood the permissions incorrectly, of this is actually the case. 

Thanks and Regards,

Ankit.

Tobi Theobald (resolution) July 3, 2018

Hi Ankit,

here are the explanations for the requested permissions:

 

Send and receive messages in conversations it's installed in; and access all the information it needs to participate in conversations:

This is necessary to receive messages and send messages (including file attachments).

It needs to receive messages in order to post them in any connected Stride rooms / Slack channels. It needs to be able to post messages to show you which messages have been posted in connected rooms / channels.

We also retrieve information about the room name to transmit that.

This (theoretically) also gives our app access to the message history, the user IDs of the users in a rooms and its topic, but we don't use this information.

 

Access user data: This is necessary in order to annotate the sent messages with its author name and avatar.

The user data that the app retrieves contains information like name, email (which we don't use here) and avatar.

When you send a message, the messages sent to connected rooms / channels are "annotated" with the user's name and avatar to signify who sent the message.

Without this permission, the app would only get Atlassian account IDs for each message's author, which would be useless when transmitting the messages to connected rooms / channels.

You can see an example for this in the screenshots on the marketplace listing.

 

Regarding your question of exposing only a single room's data: You are correct, that these permissions only apply to the rooms you install the app in and NOT the entire workspace. The app has no way of retrieving any information about other rooms and users that are not either part of or mentioned in the room that the app is installed in. 

 

But ultimately, you are right. This is still a lot of information. I hope my explanation convinces you, that all of it is either required or not used. The amount of it that is stored in our database is even less. A full explanation of which data is used how can be found in our privacy policy.

<edit>

Regarding the data saved in our databases: This amounts to

  • credentials to Slack instances,
  • the site names (in most cases this will be your company name or its *.atlassian.net domain),
  • and information about connected rooms / channels: Which is connected to which, what are their names and when was the connection established

So you see that this is a lot less than we even retrieve. Additionally, we cache some information temporarily for performance reason.

</edit>

We do take these issues very seriously and put thought into everything we retrieve and why we do it. As such, I would like to thank you for giving me chance to clarify these! If you have any further questions, feel free to ask them here publicly or privately in our customer support portal.

Tobias, Developer at resolution

Ankit Agarwal July 3, 2018

Thanks @Christian Reichert (resolution) @Tobi Theobald (resolution) for the detailed explanation. 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events