Hi everyone, there is a significant user model change planned for Mattermost 3.0 shipping on May 16. It’s been discussed with key contributors and their deployments and we want to gather more feedback and considerations from the broader community.
Design challenge
Mattermost was designed as a self-hosted solution for team communication where users were considered “team members”. A user did not exist without a team.
This became problematic for organizations with multiple teams, because one user needed multiple accounts for each team. This meant a user had to check multiple accounts in order to receive their direct messages.
Design approach
To solve this issue, Mattermost 3.0 will enable accounts to be unified across teams.
This means:
Users now create one account per server
One set of account settings applies across teams
Question: How high a priority is it to have different theme color options per team on user accounts?
The “Find my team” feature is no longer needed, any user who is logged in will be able to switch to or join any team for which they have permission
Teams can add team members from the list of members on the server, in addition to inviting non-users to create accounts via link or email as is available today
Direct messages work the same way across all teams–any user on the server can message any other user on the server without being restricted by team
How high a priority is it to add an option to limit the users added to the DM list per team to members of the team?
Account usernames and emails need to be unique across the system.
Users with accounts using identical usernames or email addresses will require some migration steps, which we’ll be working on this month.
This is a great enhancement as I think that most of the installations have more than one team and users on more than one of them simultaneously.
It’s already easier with GitLab SSO but it’s still problematic as Mattermost doesn’t take into account that two SSOs from GitLab are in fact the same user.
Will the notification settings be the same in all teams? There will be use cases where users would be mostly active on one team and rather passive observers on others. These users won’t like the same notification level on all teams.
Did you think about the “team amin” role? This one definitely has to be set per team.
The theme color per team would be a nice to have, the per team notification setting would be more important to me.
users should only be able to see and message users it they both have permission in at least one common team
DM have to be finally placed in one team area as there is no “team free” UI or do you intend to make one? If there is only one common team between the users the DM has to be placed there, but what when there are more than one? Which notification settings will be used?
That’s a really good point about notification settings, that’s probably another one that will be per team. Team admins will also need to be a role assigned on a per team basis.
For direct messages, there would only be one channel between two users but that channel would show up across all teams. So if I was in Team A and direct messaged you, I could also switch to Team B and see the same message I sent you from Team A. If you messaged me, I would be able to see the message you sent no matter what team I was logged in to.
One thing we were considering for direct messages would be to have a filter on the direct messages “More” menu to show people on the team or people on the whole server, to make it more obvious who was on a team and who was not.
Can you help me understand more about the use case of only wanting people to be able to message each other if they have a team in common? We were thinking it would be more useful to let anyone on the server message each other (kind of like a company wide directory, so you could message anyone at the company even if they were on a different team). It might be possible to make this an option in the System Console to turn on/off server wide direct messages for cases where it would be better to limit direct messages to teams, but we would need to think a little more on how that would work.
I like this idea, and I do see value in being able to message users that I do not share a team with.
Similar to the “one direct message channel showing up across all teams” behavior, it would be great to have the capability for public channels to be able to show up on multiple teams - basically the ability to flag a channel as Global.
For example, you could have 3 large independent project teams, using their own Teams, but with a shared Water Cooler global channel between all 3 teams.
It’s more about the global visibility of users. Just think of a small company who needs to communicate with a customer on a project done for him. The will already have teams set up for sales, services and so on. Now they would simply set up another team to communicate with the customer. Members would be all people facing this specific customer and all involved people from the customer.
We surely don’t want the customer to have direct access into the companies directory. Even worse, If they are have several customer projects, nobody wants a customer see which other people are customers there as well.
This could be confusing as whoever is on several teams, would need to find out which teams he has in common with the other user to understand the context. Just think about a direct message coming from a customer user. At least the direct message should not show up in teams where one of the users in not member.
I would think every company would have a “whole company” team, where everyone is member, set up as well. If you think of directories, then showing only the members of the currently selected team would make a search much easier: If you’re on the sales team you’ll more easily spot Dave, the sales guy, when Dave, the janitor, or Dave, the operations manager, aren’t on the, incidentally much shorter, list. If you want all, minus the customer people, just go to the “whole company” team.
[quote=“lfbrock, post:4, topic:1126”]an option in the System Console to turn on/off server wide direct messages for cases where it would be better to limit direct messages to teams[/quote]Limiting to teams is somehow not exactly what I would have. It’s rather prevent direct messages if there is no team in common.
[quote=“mjmst74, post:5, topic:1126”]it would be great to have the capability for public channels to be able to show up on multiple teams - basically the ability to flag a channel as Global.[/quote]This is somehow redundant, as having a “whole company” team would anyway lead to the result that people have a common channel. It’s just more fine grained in the access, since you can prevent the customers from the customer communication teams to hang around the water cooler too if you don’t include them into the “whole company” team.
Would the idea of Teams having a common Channel be different?
If I am digesting this all correctly, @BlueAnanas your point is more of access control for the channel. While @mjmst74 is talking about the availability of the channel after you have access to it.
@mjmst74’s point is that if I join a Global Channel I would expect that it shows up in my channel list regardless of what team I have active. When I send a message in that channel it would appear to each channel member regardless of what Team they have active. In other words I don’t want to have to switch teams to participate in a global channel.
Is there value add in adding that capability? There is for us (unless we have missed an existing way to accomplish that).
The resulting desktop instead of email notifications is a function I have somewhat overseen. I agree that this could be useful, specially as long as the different teams are only weakly linked.
My point was only against a general globality in the sense that once a channel is marked as global it would show up for all users irrespective of their team memberships. Even if a channel is marked as global, a user should only be able to join or even see this channel if he is member of the team where this channel is created.
I would even propose that entering that channel would put the user in the team view of the team where the global channel was created so the user gets the right context.
This is an interesting feature. Recently I completed a migration tool that merges all the existing teams into a single team. We were finding it difficult and pretty much non-collaborative to use multiple accounts across different teams.
I posted the basic code that manipulates the database here - https://github.com/vrenjith/matter-merge-teams
(This works in the scenario I have tested, while there are some issues still around the direct message migration which I am kind of ignoring for the time being)
Similar reservations about multiple teams and collaboration here. We are looking to open up information, not just compartmentalize it in a different way.
While the other side of the argument is about the scaling issues of using only one team for ~500 users, over many different projects. What does that one team look like after say 5 years have passed?
This discussion on cross-team capabilities is coming at the right time for us.
Just an update on this - since it’s a larger change, unifying the user account across teams is going to be delayed until v2.3.
Having channels that work across teams is a really interesting idea - it won’t be added right now, but we’ll have to think about how that could work. I can definitely see how it would be useful.
In the meantime, after unifying user accounts so users only have one account per site it should be possible to show some sort of indicator if you get a new mention in another team. We’d have to think about how to show the indicator, but if you can see when you have messages on another team more easily it might help with the issue of using multiple teams.
(As a sidenote - if you try out our desktop app it might also help for people who are on multiple teams).
We definitely want to build the product to work well for companies who want to use one big team instead of multiple teams I think there’s a lot of places where using one large team would be more convenient than having multiple teams.
Overall we want to have a product that works well for both situations, so end users can decide what set up works best for them.
Just curious how high a priority is it to be able to restrict DMs of users to only users who share a common team. Added a post to feature idea forums to welcome upvotes and discussion here.
To get an unbiased indication how to implement the DM feature you should also post the idea [quote=“lfbrock, post:1, topic:1126”]
any user on the server can message any other user on the server without being restricted by team
[/quote]
and then compare the success of the two entries.
However, it seems that it’s too late for the 3.0 release anyway. So I’ll have to fork and implement a config option myself
I just migrated several Slack workspaces to Mattermost. I tried to carefully rename users before importing them to Mattermost. Unfortunately, I missed two people who now have two user/email identifications.
I imagine a command like:
mmctl user merge UserA UserB --to UserA
All posts and mentions, etc of UserB will be renamed/moved to UserA.
on 1-7.
I think there’s a lot of places where using one large team would be more convenient than having multiple teams.