Support multiple orgs on the same instance

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

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

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?

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!

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

@mhurwi

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 😀

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.

👍 this is awesome

@mhurwi

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

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.

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?

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

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.

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

@liuliming2008

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

High Availability / Scaling to multiple instances.

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.

@blackandred

@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.

@engelgabriel

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 ?

@jeffix2000

@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.

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

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.

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

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.

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

[PVUL-93] xss in search messages (#658)

Navigation Menu

Repository navigation

Support multiple orgs on the same instance #658

153 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support multiple orgs on the same instance #658

Description

Activity

mhurwi commented on Sep 13, 2015

Sing-Li commented on Sep 13, 2015

mhurwi commented on Sep 13, 2015

Sing-Li commented on Sep 13, 2015

engelgabriel commented on Sep 13, 2015

geekgonecrazy commented on Sep 13, 2015

Sing-Li commented on Sep 13, 2015

liuliming2008 commented on Sep 14, 2015

mhurwi commented on Sep 14, 2015

Sing-Li commented on Sep 14, 2015

engelgabriel commented on Sep 14, 2015

liuliming2008 commented on Sep 15, 2015

geekgonecrazy commented on Sep 15, 2015

153 remaining items

blackandred commented on Aug 17, 2020

jeffix2000 commented on Dec 7, 2020

jeffix2000 commented on Dec 7, 2020

Sing-Li commented on Dec 8, 2020

Joey-Nguyen commented on Jan 23, 2021

c0reM commented on Mar 19, 2021

rasos commented on Jun 30, 2021

srajandev98 commented on Jan 24, 2022

nicolas3256 commented on Jul 21, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions