Support multiple orgs on the same instance

[engelgabriel]

Transparently divide a single server into several different instances shared between different groups of users.

Evaluate
https://atmospherejs.com/mizzao/partitioner

[mhurwi]

Hi! We might be interested in helping on this one.

Is it to be the same 'teams' feature as on Slack? Has anyone started on it yet?

[Sing-Li]

Cool. Please join the #contributors channel on the demo chat. Can definitely use the help, especially if you guys have experience in working with mizzao:partioner already!

[mhurwi]

Not used it, but reading the docs and discussion, seems like a nice solution. Will see you in the chat room soon!

[Sing-Li]

Great, @mhurwi ! Catch you on demo soon. Can't wait to see what sort of real world performance hit partitioning brings. Day job's got me running 'round in circles on a Sunday 😀

[engelgabriel]

THe good news is, I just talked to 2 companies that want this feature so bad, they will allocate their own developers to contribute and build it :)

One of the companies if from around the block, so they will just come to the office for a few days and work from here.

[geekgonecrazy]

👍 this is awesome

[Sing-Li]

Haha what a team! @mhurwi , you just got yourself some teamates from the real sunny south! 😀

[liuliming2008]

Partition is the same as "team" at slack?
At slack, one user(email)can create and join multiple teams, can can switch team.
If Partition is only a solution like load balance, rocket cloud add team feature at one instance first.

[mhurwi]

One thing about mizzao:meteor-partitioner: it seems set up to allow one user to belong to only one group.

https://github.com/mizzao/meteor-partitioner/blob/master/grouping.coffee#L19-L23

Partitioner.setUserGroup = (userId, groupId) ->
  check(userId, String)
  check(groupId, String)
  if Grouping.findOne(userId)
    throw new Meteor.Error(403, "User is already in a group")

This makes sense, compared to Slack. From my experience, Slack requires a unique new password for each team. That could mean that each team represents a new instance and behind the scenes, on Slack I have a separate account for each team I belong to.

Maybe using meteor-partitioner would require creating a new account for a user when they want to join a new group?

Not sure what you all think about this?

[Sing-Li]

Just copying a post from the other thread (use a context id):

Can we 'virtualise' the real email + an appearance id ... and then gen a unique guid email to be used by meteor?? just a thought

the appearance id might just be a 'context identifier', from which white-labeled instance (or a team name) the user is logging in from (as), for example:

(singli@hisemail.com + 'rocketchat team') -> kskfjsafosajdfasf@dsalfsakfaslf.com
(singli@hisemail.com + 'sings own family chat') -> o24i3i435o35345@oi324323432.com

[engelgabriel]

I think we should look into mizzao:partioner, but not use it, just understand it and apply some of the logic into our project. The main reason being that we want this behaviour to be optional. Some organization will just want a very simple Rocket.Chat deployment, for a single team. So we need to add the hooks on the right places, and only activate them via settings.

[liuliming2008]

I suggest to add the "team" feature as optional settings.
And then consider how to expand one instance to more.

[geekgonecrazy]

@liuliming2008 that's a completely separate thing and is being tracked here. #520

High Availability / Scaling to multiple instances.

[engelgabriel]

Lets implement that using the new abstraction layer at
Rocket.Chat/packages/rocketchat-lib/server/models/_Base.coffee

[engelgabriel]

Althou we will use the word "TEAMS" to denominate the enviroment variable, the property name on the schema should be configurable, so we can keep compatibility with https://atmospherejs.com/mizzao/partitioner as they use _groupId

[joaocarloscabral]

Hello guys.
I'll work on this issue on the next days!
As @engelgabriel said before, we have a product that needs this feature and will be a pleasure for me to help.

Yesterday I was talking with @engelgabriel and @rodrigok about the first steps to develop and the suggestion was to start changing this file: https://github.com/joaocarloscabral/Rocket.Chat/blob/master/packages/rocketchat-lib/server/models/_Base.coffee

The idea is intercept all calls to DB, add a property named as _teamId and check if the property was not changed from the client.

Right? :)

[engelgabriel]

@joaocarloscabral Take a look on the link below for how to grab the connection object for that fiber.
https://github.com/RocketChat/Rocket.Chat/compare/EnvironmentConnection#diff-e214084ef39ef04ea8cfce4bd72a420bR26

[geekgonecrazy]

@engelgabriel when I think teams i'm thinking of an organizational unit. A way to say this user is part of this team, this channel is part of this team. A way of visually organizing and displaying things. But essentially its still all in the same organization, and same instance and they could directly interact with other teams.

Like Company X has:

• Sales Team
• Marketing Team
• Engineering Team

Etc, but they can still talk in general shared channels.

When I read through this thread, this looks like you guys are talking multi-organizational support? Or partitioning of a single server to be able to take care of multiple organizations. Completely separate but on the same instance.

I'm I correct in thinking this is actually multi-organization support not really teams?

[mhurwi]

We are in favor of 'multi-organization'. We use slack this way-- each team is a different customer organization that we manage. These different organizations do not talk to each other.

'sales team' and 'marketing team' seem like people that belong to the same organization. They can use private channels to stay separate, but they can still direct message whoever they want and also join in the public channels.

[geekgonecrazy]

@mhurwi right that makes sense that you would have the option to separate out to a multi-org if you want isolation between teams.

@engelgabriel I'm going to go ahead and change this title so we its a little more clear.

[liuliming2008]

hi @joaocarloscabral and @engelgabriel:
If do ti at Rocket.Chat/packages/rocketchat-lib/server/models/_Base.coffee, can not support one user create or join mutiple organizations like slack, right?

[mindey]

How to just disable listing of users in /directory, if they are not in the groups that the user is part of? That would solve us all the problems, without having to create any abstraction layers on top. It's solved by PR #7830 (Permission: view-outside-room).

[ggruber4711]

How to just disable listing of users in /directory, if they are not in the groups that the user is part of? That would solve us all the problems, without having to create any abstraction layers on top. It's solved by PR #7830 (Permission: view-outside-room).

OK, needed some time to understand this. This essentially means, that for the Role 'user' we would remove the view-outside-room permission.

Then for each organisation/customer which is added to the single Rocket.Chat instance, we would auto-create a #Customer-General channel, where all users of the customer would be added and add ther users to there 'general' channel.

If then a user of a customer searches for other users, he would need to use the company-specific general channel in order to find his colleagues. He would not be able to find colleague with the directory though :-(

In order for this scenario to work properly, I think we would need to change the directory in such a way, that at least all users of the rooms the current user is currently in are displayed. Essentially it means collecting all the rooms of the user and merging the other users of those rooms into one set and displaying it in the directory.

Created a new issue for that UX Problem #14930

[ggruber4711]

I did some more research and came up with a pretty good configuration scenario removing these permissions:

• view-c-room (view channels)
• view-outside-room (view users outside of room)
• create-c (create channels)
• create-p (create private rooms)

Now a user can only see members of the groups he is in and he cannot create new groups or channels.

Only 2 drawbacks:

• Directory / search functionality does not show any user Restricted user can not see all accessible other users in the Directory (no permission view-outside-room) #14930
• Dialog to start a discussion allows to reference a user outside of scope (who is not part of the referenced channels) Create discussion dialog allows to query users outside of parent room #14931

[rodrigok]

We are not going to support multiple organizations as described by this issue, using the same database but splitting rooms and messages by a new key.

We are working to support multiple databases (connections, not other databases like Postgres) on our backend for performance reasons, in the way where we can share resources.

This probably will land first in our Enterprise version, since we are doing it while transforming some parts in microservices.

[rasos]

Let me propose a concept for introducing team spaces simply based on group memberships. A group or channel in RC may be set as a home base for a team. They are also representing the membership for the team. Any channel or group may have a is-part-of-team relation to any other group and channel. We would need to introduce additional permission settings like allow-add-room-to-team, view-outside-team-relations (users without that permission see only groups and channels to which their home base team group has a team relation).

In the GUI, we probably do not much more than adding a sort-by-team-membership category.

As there is now LDAP sync in both directions available, this would simplify even provisioning of teams with an LDAP group membership (so we get the management of team spaces for free in the corporate world).

[borismedovnik]

rasos proposal would fit very well into our workflow in multiple installations of RC, and it looks like it would be an additional useful feature for LDAP / enterprise customers.

[rodrigok]

Thanks, @rasos. The "teams" feature is something we would like to have. I'll explain the difference between teams and orgs:

• Teams: A logical separation of channels and users, like departments.
• Orgs: A hard split among companies, requiring to split everything from channels to server settings.

@rasos I'm not sure I understood how this would work on the UI level. Would I have a visual separation of teams and a place to select the team I want to see the channels or would it be more like a permission level to decide which channels I would have access?

[rasos]

@rodrigok agree to focus on team spaces here. Whoever needs to separate organizations should fire up another RC instance and federate channels and groups as needed. This is also the only GDPR safe solution for different legal entities.

My proposal for managing teams in RC is permission-driven. I simply also see those channels and rooms my team (and thus myself) has access to. On the UI level we probably do not even need a new category at the left navigation bar, maybe a small team icon near the room name saying "you see that room because you are a member of a team". Such a generic team icon could be replaced with an icon of the related room/channel that represents the team (we don't have an icon per room yet afaik).

Room/channels get an extra menu point Members as team with elements like:

• room shows up as a team in search directory (checkbox)
• team has access to (list of other rooms/channels with relation to own team)
• an area to define read|write|moderate|manage access to other rooms/channels (selection)
• a select box who may define those relations, either the leader(s) of the room (which is an existing concept in RC) or every team member with permission allow-manage-rooms-for-team

I like the term team, as it is more generic than a workspace or a department, and includes their meaning. The term "Circle" is probably even more generic (and suitable to modern management with "task circles" and sociocratic movements). Circles are being used in nextcloud widely and supported by most other nextcloud apps. The Circle app even allows to self-organize groups and they even can be mapped to LDAP groups there, so we would gain compatibility here: manage your circles either in nextcloud or RC and if both use LDAP that would even sync the team memberships. See also this thread on NC integration: https://forums.rocket.chat/t/gsoc-2019-deeper-nextcloud-integration-utkarsh-barsaiyan/4444/5

[ramrami]

Any progress on the multi teams (or orgs) feature in 2020 ?

[mrsimpson]

@ramrami not exactly as described „in one instance“, but there is the [federation feature](https://rocket.chat/docs/administrator-guides/federation/ https://rocket.chat/docs/administrator-guides/federation/) which allows users of separate instances to interact with each other.
And there will be progress on this end as well in 2020, afaik.
@alansikora May it make sense to close this issue after directing to an updated federation-feature-description?

[blackandred]

Is there any progress on multiple teams on single instance?

Mattermost has done it in best way - a team can be created, and each team can have as much rooms as they want. Additionally the people can speak between teams on priv.

[jeffix2000]

@blackandred IMHO the Mattermost implementation is too much of a "silos" kind, team > channels being a content hierarchy.

@rasos's proposal seems more versatile: a (real) team being a (digital) circle - either managed natively in RC or sync-ed from an identity provider like LDAP or OIDC - could have its own team channel but also be part as a team of larger communities' channels (say, a tribe and a full value stream in an at-scale organization), have some minimum-level membership in other relevant "sibling" channels, etc.

By membership I mean typical private channels or publicly readable with membership approval before being able to publish.

[jeffix2000]

I'm afraid this thread has become swinging between 2 different directions.
Being quite new here, sorry if I misinterpret, but maybe @engelgabriel the subject here could be narrowed down to "multiple isolated orgs" and tell where we should best discuss the other epic of "teams at scale".

The latter seems to have a sizeable support but somewhat scattered between, at least, feature requests req RocketChat/Rocket.Chat#204, req RocketChat/Rocket.Chat#357, maybe req RocketChat/Rocket.Chat#36 (whose categories could be the groups I'm member of)
and main issues RocketChat/feature-requests#632, #3322, #1299, RocketChat/feature-requests#660, RocketChat/feature-requests#637 ; which, except the chosen reference for this epic, could be subsequently closed as duplicates. Or have I missed a story definition already current ?

[Sing-Li]

@jeffix2000 definitely two very different streams of interest represented here.

#658 (comment)

Are you on our https://open.rocket.chat community server? Please ping me there if you are.

[Joey-Nguyen]

I have read all exchanges. But it doesn't seem to have been implemented.
Can someone tell me why? Thanks

[emaktech]

We are actively looking for an open-source Slack/Teams style alternative that supports multi-tenant installations. Typically multi-tenant is handled by putting each tenant on their own domain/subdomain.

Broadly speaking, it can be accomplished by adding a new primary key in every database table specifying the tenant something belongs to. Definitely a lot of work for a big project like this, but there is huge potential for carriers and/or service providers to have a multi-tenant solution.

[rasos]

After some intense discussions, an analysis of use cases and a detailed specification, a teams feature has been made available with RC 3.13. This allows to define teams just like a channel and assign channels to that team. See https://docs.rocket.chat/guides/user-guides/teams/teams-channels

Teams may help to structure your organization or community. For a multi-tenant setup you still may require to set up a rocket chat instance for each tenant and federate. That way users can reach private rooms or direct messages on other instances https://docs.rocket.chat/guides/administrator-guides/settings/federation

[srajandev98]

Hey all!

I am a big fan of RocketChat.
In order to solve the issue of separate organizations, I am using separate databases for each of my clients.
So let's say my MongoDB instance remains the same. I just create separate docker containers for my clients and connect them to my single MongoDB container.

In this manner, all my clients are in isolation. And there is no cross-organization interference.

Hope this helps.

[nicolas3256]

There is a way to users see each other in differents team? I want to divide my workspace in sectors, but with the teams didnt work well because you need to be a member to see respective members of the team