Rocket.chat: 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

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[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 :grinning:

[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]

:+1: this is awesome

[Sing-Li]

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

[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:

([email protected] + 'rocketchat team') -> [email protected]
([email protected] + 'sings own family chat') -> [email protected]

[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?

[engelgabriel]

@liuliming2008 We will do it in a way to allow a user to join multiple organizations... or I didn't understand you question...

[liuliming2008]

@engelgabriel I see you said "Lets implement that using the new abstraction layer at
Rocket.Chat/packages/rocketchat-lib/server/models/_Base.coffee", I think this cloud be not the way to allow a user to join multiple organizations.
You now do it in another way, and I have no question.
thanks

[artisin]

I have not had the time to sit down and really look at RocketChat's code base but would a implementation that leverage minimongo for latency compensation be a better solution? Correct me if I'm wrong but if we implement a solution of that sort it would grant us a bit more flexibility in terms of privileges and roles without making a potentially expensive server call.

[Sing-Li]

Please elaborate. Interesting idea. Are you suggesting 'client side' only multi-teams?

[engelgabriel]

@artisin Meteor apps use minimongo for latency compensation as default. Can you elaborate?

[artisin]

Sorry, but after briefly looking at how you handle things I'm going to say disregard my previous comment. Although, to make sure I'm on the same page here the plan is to create a new LiveResultSet for each team?

[rodrigok]

@artisin, users will access one team per connection, so if you access the chat application in 2 tabs you can access 2 different teams in the same time using the same account.

[artisin]

Thanks @rodrigok. Elegant solution, compared to a alternative like publication overloading.

[engelgabriel]

Hi @joaocarloscabral

I am back from holiday! :) Can we create a PR for the changes done to date?

[neurobe]

There will be "Teams" delimited by Role (ie delimited by the impending Moderator/Supervisor role who might have Admin permissions over a set of Rooms) and "Teams" delimited by Partitioning.
Given that, I think "organisation" is a better term than "teams" for the latter. In my understanding, for Partitioning, each instance will have its own badge, which might say "Team No1" or it might say "General Electric Boston". Happy to have my understanding corrected.

The former seems straight forward to implement. The latter seems a brave new world. Love to have both of course.

[engelgabriel]

We agree that "organisation" is a better term than "teams". We may have both in the future, but this issue is related to "organisation". The main difference being that users/rooms/messages from "organisation" would be completely invisible/isolated to users/rooms/messages from another "organisation" on the same server. What we are trying to achieve here is a multi tenant database architecture with shared database and shared schema.

[bnusunny]

We are also working on the multi-tenant support and hit a road block. We need your advise.

We started with mizzao:partitioner package and partitioned all the models in _Base.coffee.

packages/rocketchat-lib/server/models/_Base.coffee:5

    _initModel: (name) ->
        check name, String

        @model = new Meteor.Collection @_baseName() + name

        Partitioner.partitionCollection @model

However, Rocket.chat can't run with this change.

W20151129-14:13:33.309(8)? (STDERR) 
W20151129-14:13:33.309(8)? (STDERR) C:\Users\Harold\AppData\Local\.meteor\packages\meteor-tool\1.1.10\mt-os.windows.x86_32\dev_bundle\server-lib\node_modules\fibers\future.js:245
W20151129-14:13:33.309(8)? (STDERR)                                             throw(ex);
W20151129-14:13:33.309(8)? (STDERR)                                                   ^
W20151129-14:13:33.309(8)? (STDERR) Error: Must be logged in to operate on partitioned collection [403]
W20151129-14:13:33.309(8)? (STDERR)     at Object.findHook (packages/mizzao_partitioner/grouping.coffee:153:15)
W20151129-14:13:33.309(8)? (STDERR)     at packages/matb33_collection-hooks/find.js:12:1
W20151129-14:13:33.309(8)? (STDERR)     at Array.forEach (native)
W20151129-14:13:33.309(8)? (STDERR)     at Function._.each._.forEach (packages/underscore/underscore.js:105:1)
W20151129-14:13:33.309(8)? (STDERR)     at Object.CollectionHooks.defineAdvice.self (packages/matb33_collection-hooks/find.js:11:1)
W20151129-14:13:33.309(8)? (STDERR)     at Object.collection.(anonymous function) [as find] (packages/matb33_collection-hooks/collection-hooks.js:117:1)
W20151129-14:13:33.309(8)? (STDERR)     at [object Object]._.extend.find (packages/mongo/collection.js:283:1)
W20151129-14:13:33.309(8)? (STDERR)     at _Class.RocketChat.models._Base._Class.find (packages/rocketchat_lib/server/models/_Base.coffee:14:22)
W20151129-14:13:33.309(8)? (STDERR)     at __coffeescriptShare (packages/rocketchat_lib/server/startup/oAuthServicesUpdate.coffee:51:28)
W20151129-14:13:33.309(8)? (STDERR)     at packages/rocketchat_lib/server/startup/oAuthServicesUpdate.coffee:1:1

Checking the code, we found that models methods were used during Meteor startup. At that point of time, no user was logged in and can't determine the tenant.

packages/rocketchat-lib/server/startup/oAuthServicesUpdate.coffee:51

RocketChat.models.Settings.find().observe
    added: (record) ->
        if /^Accounts_OAuth_.+/.test record._id
            oAuthServicesUpdate()

    changed: (record) ->
        if /^Accounts_OAuth_.+/.test record._id
            oAuthServicesUpdate()

    removed: (record) ->
        if /^Accounts_OAuth_.+/.test record._id
            oAuthServicesUpdate()

In our case, different tenants should be able to maintain their own settings besides rooms/messages/users. Is it possible to move these tenant related configuration code outside of Meteor startup and call them later when tenant information is available?

[steedos]

Hello guys, we are working on a admin dashboard project, plans to support multiple teams on the same instance.

https://github.com/steedos/admin

We separate users to spaces, one user can join multiple spaces. We'll be glad to integrate this to RocketChat as an Admin UI for Space Owners.

[artisin]

@bnusunny I ran into that same error a while back while working with Partitioner did you try wrapping it in the Partitioner.directOperation method?

[IQ2022]

how about multiple sites, different groups -- transparent to site users (each site user stay within their group)

[liuliming2008]

@steedos
I can say that: the space equals channel at slack/rochekt.chat, and organizations in your screenshot equals organization at slack/rochekt.chat?

[steedos]

@liuliming2008 , sorry for reply late.

Spaces equals teams in slack, which may have a domain name
Space_Users contains users joined the space, one user can join multiple space.
Organizations is departments inside space, it is a tree model, user can in multiple organizations

Space has a owner and admins
Space admins can modify space users and organizations
Space admins can add space users via email, if email not exists in users collection, system will create a new user, send invitation can add the new user to space.

some api references here.
https://github.com/steedos/api/tree/master/core

[liuliming2008]

@steedos:
Good project.
Spaces means company or teams in slack, which may have a domain name.
And Organizations means departments inside space, a tree model.
If can integrated with RochetChat(admin can create channels with organization members, not one by one), it will more flexible on channel member management than Slack.
I dont think rocket team will do similar work recently, "Support multiple orgs on the same instance " is hard work and they need time to improve this I think.
Looking for your demo work.

[steedos]

@liuliming2008, thanks for your advice.
The organization can also be used to browse users by department in tree view, for large organizations.
the admin panel is ready to work now, i will try to integrate it with rocket.chat in the next month.

[srocke]

@steedos How is this coming? Wanting to do multi-tenant offering (different companies using different domains) and curious as to the progress. Thanks.

[jalagrange]

This would be amazing! Any updates?!

[ToxikCZ]

+1
Do you have some estimate for release?

[Megatronic79]

+1

[liuliming2008]

very difficulty, almost need to rearchitect, let's wait

[srocke]

How is this so difficult?

Sent from my iPhone

On Feb 3, 2016, at 1:06 AM, liuliming2008 [email protected] wrote:

very difficulty, almost need to rearchitect, let's wait

—
Reply to this email directly or view it on GitHub.

[dalareo]

+1000 @steedos how can I integrate rocket.chat in Steedos Admin??

[IQ2022]

so we can have one admin or site owner to manage the different groups and allow who can view a shared rooms (common rooms) - in the same it can be transparent, one challenge i may think of is the URL address probably we need to come with something fancy, to change it or probably dedicate a URL just for Chat?

Also how about oauth would that still apply, users from one site can't access the chat room if they are not verified users, regardless

[cbrummitt]

I'm looking into using Rocket.Chat for a research experiment in summer 2016 that will involve about 20 teams with ~250 users each. This feature and @steedos 's dashboard seem like the ideal tool!

[beatelite]

+1. Looking forward to this.

[frdmn]

:+1:

[telemakhos]

Watching... :+1:

[kramer65]

Watching. We also need this badly! :+1:

[marlene194]

Watching... :+1:

[byhub]

I tried to reach @steedos but got no response.. and asked few rocketchat guys and they were not clear either.. so I assume there is no one actually working on this issue currently?

[rodrigok]

@byhub Yes, you are right, we are no working on this feature right now.

[steedos]

Hello guys, sorry for reply late. we are working on steedos backend to support multi teams in one instance. and just released the first version. https://github.com/steedos/apps/ , with a demo at https://us.steedos.com/

When we try to start the rocket chat intergration, we found the following problems:

1. username in rocket chat are unique, means users in different teams must have unique usernames, it's a small problem
2. room names are unique, means if one team have a room named such as "HR" ,"Finance", "Jobs", no other teams can have that name.
3. User will confused if there is an general channel with a lot of people unknown. Instead every team should have a team general channel.

[dalareo]

Hi @steedos, is Steedos ready to install in our own server?? We are planning EduCaaS integration with similar services (Sandstorm-like)

[steedos]

@dalareo Yes, steedos can install in your own server. you can use the admin app, and we will release a cms app in a month, only the workflow app need an extra workflow engine server written in ruby, and we have a plan to transfer the old ruby server to meteor.

[codyaray]

@steedos https://www.steedos.com/us/chat/ is this a bundled rocket.chat of some sort? or an independent slack clone? does it already have multi-team stuff?

[steedos]

@codyaray, Yes, It is a bundled rocket.chat, It's not a multi-team stuff.

[beatelite]

What's the good word on this so far?

[msears]

We are also looking for this, a multi-tenant architecture for rocket.chat, preferably with subdomains for each tenant. Anyone else have any progress here to report, am thinking about adding a bounty if that would help.

[ebayaraa]

When status to be changed to release?

[jelenajjo]

Any update on this guys ? @engelgabriel @rodrigok

[anandsork]

I am also looking for this.

Meantime, is there any other way to simulate multiple organizations on single instance? Like running multiple instances of Rocket.chat on different ports with different DBs? How many such instances can be run?

There was some discussion around Partitioner & error while using it. artisin had suggested some wayout (https://github.com/RocketChat/Rocket.Chat/issues/658#issuecomment-161090283), but there is no discussion after that. Will that fix the thing?

[codyaray]

@anandsork you should be able to run multiple processes on different ports with different DBs behind a load balancer to proxy chat.example1.com -> localhost:3001, chat.example2.com -> localhost:3002, etc.

In the init scripts for each process, set the MONGO_URL to mongodb://localhost:27017/rocketchat1, rocketchat2 etc. (It doesn't matter what these are; they're created when you start the process.)

Here's a tutorial for running multiple processes on one instance for performance. It'll be a similar idea but with more frontends in the load balanacer and differently-configured upstart scripts.

[anandsork]

@codyaray , Thanks a lot for your input. I shall try this out.
Is there any link for the tutorial you mentioned? Seems that it got stripped off in the message.
Load balancer with upstart scripts seems to be great idea.

[codyaray]

Weird, here it is again. Sorry about that.

https://rocket.chat/docs/installation/manual-installation/multiple-instances-to-improve-performance/

[MikeDaniel18]

I'm slightly confused, this seemed to have a lot of attention from the Rocket.Chat team in late 2015, but it doesn't seem to have been implemented. Has it?

[urbanpt]

No it hasn't. I haven't found anything besides this commit mentioned in #630.

[mfilotto]

Any news on this one please ?

[DMW007]

@codyaray That's a load balancer environment. As I understood this ticket, it's about having some kind of teams in Rocket.Chat like Mattermost has. In Mattermost, you can create different teams, that are independent from each other, but share the same user-base. For example you can create TeamA and TeamB. Now when UserA creates an account, you give them access to TeamA only and UserB to TeamB.

In this case, UserA can only see TeamA and wouldn't even know about TeamB. The benefit is, that its possible to have an user in multiple teams. Like give UserA access to Project1 and Project2, but not Project3 or Project 4. The UserA has a single account for all his teams.

That's the problem what let me discourage from using Rocket.Chat: I need to create two teams for different projects. which are independent. But as I'm mentor both projects, I need to be a member of both too.

With Rocket.Chat, the only solution seems to be create two different instances. This wouldn't result in a good user-experience since I have to logout from ProjectA's instance to use ProjectB's instance. Consistent notifications on a mobile device wouldn't be possible, cause I'm only logged in to one instance at the same time.

It's pity that Rocket.Chat doesn't offer such a feature. I tested Rocket.Chat and Mattermost, and liked Rocket.Chat more. But I need two teams, so I have to use Mattermost, since this feature doesn't exist in Rocket.Chat.

[chellem]

@DMWOO7 I've been able to manage teams, that is upon creation of a team in Rocket.Chat, another instance of Rocket.Chat will be created, each one separated and each has it's own database and using nginx as a proxy server and access different teams from a single url. The problem of authentication can be resolved by the use of API, so the switching between teams is possible.

[tmtben]

Please @chellem , could you explain us?

[bannostookaylo]

Why cant there just be a teams collection with a "company ID" and then a user belongs to that company and then they can only access things associated with said company ID... maybe I don't understand MongoDB that well but I'd love to include this with our software but we need to figure out how to implement such a feature. :)

[tareko]

Hello all,

I am currently evaluating rocket.chat for migration from mattermost. Huge advantages include the ability to use rocket.chat's enterprise features in an open source version (especially SAML for us).

However, this feature is killer in mattermost. Could those of us interested in this feature put a bounty on it? I am happy to contribute! I've put my bounty in bounty source as indicated above (see here).

Thank you

[FrederickLjungberg]

Happy 2 year Anniversary (of this issue being ignored by the admins)!

:birthday::birthday::birthday::birthday::birthday:
:balloon::balloon::balloon::balloon::balloon:
:tada::tada::tada::tada::tada:

[Creanimo]

This would be such a helpful feature. How much work is still needed? (or more directly put: How much bounty would be needed to get this done?)

[urbanpt]

@FrederickLjungberg You're welcome to start some work on it

@Creanimo I agree. I'm available to help either with coding or with the bounty.

[geekgonecrazy]

This feature request is for sure not ignored. We are well aware of it. It's a significant amount of work. A lot of the stuff we are working on will lay the ground work for this feature.

[KVSocial]

following - would love to see this feature.

[jmordica]

Following!

[ZhaoVitapublic]

Following - This would be very nice feaure.

[hridayeshgupta-mt]

would love to have this feature!
Is there any branch where development for this is going on?

[juliomac]

It would be nice indeed! Following

[AustinFelipe]

Does anyone know if there is a branch in progress?

[SRSaddler]

+1

[42robotsCS]

+1

[42robotsCS]

Referring to the spaces idea:

This is a very nice Pattern to use for such a usecase. Is there any update concerning the mentioned idea of a possible rocket.chat integration?

[jk2081]

+1

[torgeirl]

This feature request is for sure not ignored. We are well aware of it. It's a significant amount of work. A lot of the stuff we are working on will lay the ground work for this feature.

@geekgonecrazy are you able to elaborate on what you're currently working towards? For instance, would it be something similar to Mattermost's (and Discords?) model with one user on the server that can join/be added to more than one team, or like Slack where the user can switch between different accounts on different instances (/servers) in the UI?

Besides the leak of PostgreSQL support (issue #533) this is a show-stoppers for my employer to consider Rocket.Chat over Mattermost which we're testing out now.

[tompinzler]

We are currently evaluating different chat software and fell in love with Rocket Chat. But missing that particular feature is a blocker for us. Is there any vague ETA I can convince my management with to bet on Rocket Chat? Is it possible to sponsor development on this to speed things up?

[GustavoAmerico]

This issue needs documentation summarizing these two years of conversation and pointing out the points that the community can help

[geekgonecrazy]

We might should actually title this issue multi-tenant.

There are pretty much two different things at play here.

Multi Org

You'd be able to completely isolate organizations and their teams from each other.

Something like one server being able to handle:
chat.something.com
chat.something2.com
and both have isolated users and channels while utilizing the same CPU resources.

Multi team per Org

Being able to have teams in an organization. These teams would have their own channels, users would belong to those teams. But they would also be able to have shared channels between teams.

Where we are

We are likely much closer to the second one. The first one is what this issue is actually for.

[tompinzler]

Depending on how the actual implementation looks like "Multi team per Org" would include a lot of aspects of "Multi Org".

Creating a team for each organization on the same server should provide enough isolation between organizations for most use cases.

We are likely much closer to the second one.

Would you mind being more specific on this? Are we talking about an ETA of weeks, month, years?

[geekgonecrazy]

Would you mind being more specific on this? Are we talking about an ETA of weeks, month, years?

I don't really have a solid ETA. But I can say: Not years. But probably not weeks either. Its on our Mid-Term roadmap, a few months out would be best estimate currently. Of course things can always change :)

If a contributor wished to help out on making this a reality we would definitely help out and try to help them land a PR.

[vodkhang]

@geekgonecrazy I need multiple org to utilize resources somehow, but even a modified version of Multi Team per Org may also work. I have been modifying rocket.chat for a while to help with my new product. I understand the Meteor and NodeJS to some extent.

how can I help, and how is the process?

[geekgonecrazy]

No work started directly on this. It's a very big under taking. I think it will be a bit easier to say how you could help once we go into planning stage.

[vodkhang]

@geekgonecrazy: you mean even the second one, "Multi Team per Org" still hasn't started? I can code with your team for about 10 hours / week for 3-4 months, and then depending on the situations, have a dedicated developer work with your team for 2-3 months. That is only for the "Multi Team per Org", right?

[isdneuroimaging]

Multiple teams per org/server is in my view the only major point where Rocket.Chat is still behind the competition. Major point as in potential deal breaker for many scenarios/deployments.

[MikeDaniel18]

@isdneuroimaging in Jan '17 I asked to see if anything had been done. It hadn't, it still hasn't, don't hold your breath. I'd check out Mattermost as an alternative. It's very robust and feature rich, though I hate ReactJS with a passion.

[urbanpt]

@isdneuroimaging What competition (besides Mattermost)?

[isdneuroimaging]

@urbanpt Zulip also offers multiple organizations per server.

[tompinzler]

@geekgonecrazy @vodkhang I‘m not a developer but would like to help on this as well. I could do financial sponsoring. Not huge amounts but something to make things a bit easier.

[vodkhang]

@MikeDaniel18 I also hate ReactJS, that's why I didn't choose Mattermost @geekgonecrazy any update?

[42robotsCS]

Could this be managed only on a groups/permission level?
Wouldn't it be "enough" (as a first step) to "group" channels? So you could define an Org as a Group.
This can come in handy if you have a lot of channels running.

Just to mention a possible usecase:

You have a channel for organizing let's say an association - there you have different groups responsible for different tasks inside that association.
The association is part of a larger community. So everything happens within that single instance.
Having the possibility to just group channels and manage them by permission would be really nice :-)

[dominikmauritz]

I'm also interested in hosting different companies on the same server.

Organizing users in different teams and making sure that a user only sees conversations and other users of teams to which he was invited would be sufficient for my use case.

[marceloschmidt]

We're keeping this issue open as a discussion but it's not in our plans to add this in 2018.

[pa-de-solminihac]

@engelgabriel added the stat: in progress label on 13 Oct 2015

@marceloschmidt I guess you mean this label should be removed.

[mnlbox]

I think something like we have on Slack can be very useful. (worksapce with sub domain support)

[kostiag]

I have been looking for a chat solution that could reside within multi tenants saas web application that can be integrated within the app (iframe seems the only option). Any ideas when this could possibly be available? Assuming that the user can belong only to 1 organization, and my application can keep track of the channels that belong to the organization, wouldn't be be possible (or is it possible) to limit available channels based on this information for any user within organization (my app would keep track of that of course, I was thinking some kind of filtering ability?)

[mnlbox]

@engelgabriel Any chance to see this in roadmap?

[SteveUNSW]

@mnlbox Roadmap in the readme

@engelgabriel @marceloschmidt This is a must for my org as well! Happy to contribute sponsorship to make it easier on your guys.

[L-U-C-K-Y]

Hi all

We would also like to contribute to realize this feature!

Does someone have a high-level plan how to approach this feature?
What are the primary database calls and methods we would have to reengineer?

Happy to help!

[ggruber4711]

+1
I would love to see this feature as well. We have multi-tenant HR webapp which would strongly benefit from a Rocket.Chat integration. However the tenants need to be seperated. the only cross-org chat would be between tenant and Sass-Operators (Support)

[SteveUNSW]

+1 we have a workaround at the moment where we just have multiple instances on a server with different domains (chat1.domain.com and chat2.domain.com) but its super inefficient.

Any ideas on how to make this better?

[chellem]

+1 we have a workaround at the moment where we just have multiple instances on a server with different domains (chat1.domain.com and chat2.domain.com) but its super inefficient.

Any ideas on how to make this better?

Make a master instance and from it, the ability to create as many instance that you want dynamically.

[L-U-C-K-Y]

+1 we have a workaround at the moment where we just have multiple instances on a server with different domains (chat1.domain.com and chat2.domain.com) but its super inefficient.
Any ideas on how to make this better?

Make a master instance and from it, the ability to create as many instance that you want dynamically.

@chellem could you elaborate? What do you mean by master instance?

I guess that multiple processes could be started from the same directory with different starting parameters (point to different DB's). Also some details here.
The downside is that achieving high-availability, cost-effective scaling and cpu utilization becomes a real challenge. What are your ideas?

[42robotsCS]

I wonder: is there maybe a reliable setup idea with docker ? Does it make sense to use multiple containers to manage your instances and use a single database for all those instances? While thinking of it ... this could work. This might solve the issue on a intrastructural level. Also i know that "Groups", "Spaces" or "Orgs" are actually a slightly different usecase ...

[torgeirl]

I read at lot of the comments in this issue as asking for a way to organize a Rocket.Chat instance into units similar to Slack workspaces or Mattermost teams.

Running multiple instances in Docker containers could to some effect emulate that, but would be much more work to maintain and in my opinion not be a good option for many here who's just asking for some way to keep users separated.

[GreatEmerald]

"Multi team per Org" is what I'd be looking for. Completely isolating instances can already be achieved by using several subdomains, as mentioned. But it would be a great feature to be able to group channels so that they are organised better, while still being able to talk to everyone. (You can work around this right now in Rocket.chat by using standardised prefixes, but they get rather long and cumbersome.)

Matrix seems to do well in that with the "community" concept. Mattermost "teams" are a bit worse in that there is no support for cross-team channels so far, so it's more isolating.

Probably ideal would be to have a hierarchy of grouped channels, so we could have general channels for everyone, channels for a particular organisational unit, and within it channels for a particular topic. Everyone could still access any channel but they can find them easier by following the hierarchy.

[Sing-Li]

@GreatEmerald The new Threaded Discussions feature in release 1.0-BETA may already do what you need. Please take a look.

The UI (including nesting) is still evolving.

With Federation, cross-domain isolations can be relaxed in a selective and controlled manner.

[juliomac]

Hi @Sing-Li , thanks for the information. But I quite did not understand how this "threads" implementation relates to "multiple orgs on same instance". How would you think we could leverage this for that purpose? It would be excellent if that could solve it!

[Sing-Li]

@juliomac That was a reply very specific to @GreatEmerald 's exploration.

Throughout this arduous journey of almost 4 years (since the start of this issue - and multiple public/private attempts to implement something usable), we've learnt the hard way that NOT EVERYONE has the same requirements in this area. And that a sizable population of the real requirements fall towards what @GreatEmerald suggests - and _might_ be solvable with this approach.

[GreatEmerald]

Threads is a great feature that is a big added value to the platform. But threads are very short-lived, they're complementary with the concept of "communities"/"teams". Basically as far as I can tell their use is to structure short topics within a room, rather than to act as rooms within a group of rooms.

[Sing-Li]

@GreatEmerald you've gotta try our implementation of Threads then.
Lifecycle is in your control. Can be as long lived as the server itself.
It is also absolutely rooms within room - that's how it is implemented, actually.
We've spent a lot of time working out how to make "threading" actually usable by a majority of users - and this particular implementation _might_ do it.

[GreatEmerald]

Perhaps to make it a bit more visual, I'm thinking about a Rocket.Chat instance for a university. There are multiple departments or faculties; each department has multiple chair groups; each chair group organises a number of courses. Each course can have several rooms (e.g. #announcements and #questions-answers). Each room can have a big amount of threads, for instance a question on #questions-answers.

As it is, we have the lowest part of the hierarchy, and we could work around the lack of the higher levels of hierarchy with prefixes, but then the name of the #questions-answers room name would be #esg/grs/geoscripting2019/questions-answers, which is unwieldy and error-prone for misspelling.

[Sing-Li]

@GreatEmerald just quoting the earlier post

"Multi team per Org" is what I'd be looking for. Completely isolating instances can already be achieved by using several subdomains, as mentioned. But it would be a great feature to be able to group channels so that they are organised better, while still being able to talk to everyone. (You can work around this right now in Rocket.chat by using standardised prefixes, but they get rather long and cumbersome.)

Not the entire namespace needs to be partitioned via threads. Perhaps, the use of isolated instances (subdomains) can help with the higher levels. Sharing, between these "hard partitioned" spaces, can possibly be relaxed in a controlled manner via Federation. (allows sharing of users and channels between instances).

It is only in the lower levels - that this "rooms within room" thread implementation will be useful.

The "too many threads", "unwieldy" problem might be solvable with some UI ingenuity.

[GreatEmerald]

In my case, the hard partitioning Slack style isn't desirable, since it would be bad for cross-organisation collaboration. Also, we have just one LDAP instance for the whole university.

But yes, I agree that support from the protocol level isn't necessary, UI trickery could as well work. But it would be convenient, because you want different people to be admins of the different groups. (Though I guess that's a separate issue.)

[torgeirl]

@Sing-Li: this approach might be a solution for some, but it isn't comparable to Slack workspaces or Mattermost teams.

One scenario that warrants something comparable is when you have smaller teams/workgroups that use it more internally:

• general channels becomes noise and steals UI real-estate.
• it's hard to control something similar to team/Workspace admins (admins without sysadmin privileges) for that team/Workspace.
• it becomes easy to post secrets in open channels by mistake
• managing bots for that team/workspace gets messy
• it might also become harder to make sure uploads related to that team gets deleted after its done (GDPR)

As mentioned earlier you can do this by running each team in containers, but that complicates other stuff again and is not a practice solution for many.

Please stop looking at halfway fixes, and rather focus this discussion around how Rocket.Chat could get its alternative to Slack workspaces /Mattermost teams. :pray:

[Sing-Li]

Right. It is a very separate issue 🙁 This "thread" (pardon the pun) had split into two rather mutually exclusive prongs:

1) those who wants MULTI-TENANCY on one server
2) those who actually just needed some level of scoping of object visibility, accessibility and manageability within a very large server instance

Admittedly, some requirements overlap the two, But my exploration thus far, is completely addressing only a (good sized) subset of (2).

[GreatEmerald]

Yes, it's what @geekgonecrazy said, there's "Multi Org" and "Multi team per Org" ideas that are quite different in scope.

[juliomac]

Thanks @Sing-Li ! If I understood it well, threads is some sort of "conversation grouping" so people can relate to a specific subject within a larger channel, right? That's a fantastic improvement! However, like you said, it may not solve the 2 main requests you mentioned.

I am trying to achieve some sort of "multi-org scoping" for LiveChat, using departments. With each department being a different organization. So far, from what I am seeing, it almost completely solves the team/workspace/multi-tenacy request. But only works for LIveChat. In fact, the goal of departments was to get some scoping of visibility (your number 2) for departments.

I would say that the "department" solution could be further explored. Maybe just creating an "organization" field on top of department and include it on all messages/rooms/channels and control its access by roles, just like is done in livechat, could be just as fine. Going all the way with mizzao/partitioner seems daunting.

What do you think?

[juliomac]

By the way... anyone knows of this PR?

https://github.com/RocketChat/Rocket.Chat/compare/develop...leonardoterrao:develop

[torgeirl]

@juliomac: the URL is broken.

[Sing-Li]

I would say that the "department" solution could be further explored. Maybe just creating an "organization" field on top of department and include it on all messages/rooms/channels and control its access by roles, just like is done in livechat, could be just as fine. Going all the way with mizzao/partitioner seems daunting.

@juliomac That's precisely the direction that we're exploring at the moment. A note to those who are on "Prong 1" though. That the number of departments we're working with will be 10s or low 100s at the limit.

[juliomac]

Hi @torgeirl , strange... it works for me.

Please test this: https://github.com/RocketChat/Rocket.Chat/compare/develop...leonardoterrao:develop

[juliomac]

Dear @Sing-Li , please let me know how could I help there. I have some experience with Meteor.

[mwells3work]

Is there a good branch that we could evaluate what has bee done so far with the multi-org development, as we have a need for this, we could devote some time to getting it working.
thanks

[juliomac]

Hi @mwells3work ! Also for me! I would gladly help. By the way, have you seen the branch I just posted above?

[mwells3work]

@juliomac I have not looked at it yet, If you think this is a good place to start, I will check it out and test the multi-org functionality. Thanks

[ggruber4711]

For implementing a multi-org feature, wouldn't a naive approach be to have:

• organisations as new entity
• obligation to link each user to an organisation, existing installations could be updated by a "core" organisation, where every existing user is automatically linked.
• add functionality into core that users would only see messages, users etc. only from own organsation
• add special role to allow cross-organisation communication/administration for sysadmin users

That would probably solve the most important requirements in the multi-org domain.

[ggruber4711]

A poor man's solution could also be:

• add custom field 'organisation' to both user and room
• implement a proxy around rocket.chat server which intercepts any request and will filter out users and rooms based on the organisation custom field.

Goal would be that a user, which has set the organisation custom field would only see users and rooms of the same org.

[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 #14930
• Dialog to start a discussion allows to reference a user outside of scope (who is not part of the referenced channels) #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 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 #204, req #357, maybe req #36 (whose categories could be the groups I'm member of)
and main issues #3350, #3322, #1299, #12119, #2049 ; 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.

https://github.com/RocketChat/Rocket.Chat/issues/658#issuecomment-473596248

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