Mattermost-server: Non-admins can archive channels they belong to but did not create (updated title, "Delete Channel" has been deprecated)

[realrolfje]

Summary

Any user in Mattermost can delete any channel, regardless of wether they are member, channel admin, system admin.

Steps to reproduce

1. As user A, create a public channel
2. As user B join the public channel.
3. From the menu at the top, choose "Delete Channel"

Expected behavior

Members can not delete the channel or edit purpose or info, only post.
Channel Admins can delete channels and or change settings/members
Team Admins can delete channels or change settings/members

Observed behavior

Any channel member can modify and delete a channel.

At the moment this is a very big problem for us, as there is no undelete, and we have to manually update the database and restart mattermost every time somebody clicks on "Delete Channel" instead of "Leave Channel", which are right next to eachother in the menu.

Possible fixes

Apply proper channel rights.
Add integration/API/UI tests for this so that it can not be re-introduced after fixing.

[danilvoe]

This possibility is available in the ITS version of the Matternost. :(

[realrolfje]

You are kidding me, right? I need to fork Mattermost-platform and fix this so that our non-profit public service Mattermost with well over 300 users will get sensible security settings?

In our case, the E10 license would cost $1.67 * 340 = a whopping $568 per month to run on our self-hosted server with our own volunteer admins. We don't have that (or any) money.

Is the Mattermost company sure that it wants to be an open source company, supporting the open source community? At the moment it feels a bit like it is leeching on the open source community.

[JeffSchering]

@realrolfje Non-profits are eligible for a very low flat-rate fee for up to 1000 users. See https://about.mattermost.com/mattermost-mondays/

[realrolfje]

You might want to sit down for this:

From your non-profit page: "An eligible organization needs to be an official not-for-profit or charity, and also non-government, non-academic, non-commercial in nature, with no religious affiliation and that would otherwise not be able to afford the commercial version of Mattermost software."

We are not a charity. We are a club. The club is not about charity or software. Yet we are your free contributors. We are contributing to mattermost with the open-source mindset: Some of our users are in your mobile app beta-test team. As software developer I tried join development on your mobile app (didn't work because of JavaScript and XCode dependency troubles taking too much time to set it up). I dillegently report bugs on mattermost-platform and provide ideas for features and have accounts on all three of your bug/feature/bug tracking systems. I forked the mattermost-platform and am looking into golang to help work on that and/or provide better issue reports.

As I have said earlier: As professional software developer I understand the choice to cripple/disable features in the "free" version which are valuable and sellable so you can make money by enabeling those (a "hostage model" I wouldn't choose, but okay). For those features, I am happy to create local workarounds or take the pain of not having them.

But from open source software, which I actively contribute to, I expect at least basic security and safety features, as described in the password security issue I created which you just closed with a link to the documentation without fixing the actual security issue.

Any user being able to delete valuable channels on our server is in the same category. It makes no sense, and is toxic in a situation where users get into an argument or are disgrutled because of something that happens in a club (which always happens when people work together, as proven by this very issue).

Up to now, Mattermost has been a success in our club, and we were fine with this being a product in development which lacks the UI polish of its big competitor. The nice reactions and speed of your team, promising functionality and my stories at lunch even put Mattermost on the radar at my dayjob.

I was really hoping that money would help your for-profit development team without affecting open-source values, but here we are, discussing very basic security features one would expect to be in the basic version of the software.

On behalf of the open source community and the people who spent hours of their spare time to add features and fix bugs just for the fun of it, I hope you'll reconsider your stance on basic security features one (or at least I) would expect from an open source software project. I'm not in it for the mugs.

Meanwhile, our community is affected by this bug (yes, bug) and I have to manually restore channels in the database and restart mattermost almost weekly. I will be looking into how to get this basic feature to work, either by blocking that API call in our webserver, or forking Mattermost alltogether and distribute our own version.

Pending your answers on this issue and the "short password" issue linked above, I will also look into sharing that solution with others, hoping to combine it with a fix for the password problem, because above all, open source is about workig together and contributing to society which expects and deserve basic safety and security features.

[danilvoe]

This is very sad, but at the moment this is a fact with which there is little to be done. We made a decision for ourselves to fork and gradually (as we get to know Go and React, etc.) we add and correct the absurd problems of safety in the version of the CE. :(

https://about.mattermost.com/mattermost-mondays/
$50/year flat rate for up to 1000 users.

Being a state organization, we can not just pay someone else, we need official bidding, competitions, etc.
And potential users we have> 25 000 :(

[realrolfje]

Not sure what you mean with CE, but is your fork public? Is there a list of bugs/features you fixed, and is it truly GPL licensed, as in: not crippled for open source users?

[danilvoe]

As far as possible, we will offer our own refinements in the form of merge request. We have just started the process of introducing ourselves and do not want to present raw and incomplete improvements to the community.

[it33]

Hi @realrolfje

1. First, huge thanks to both you and your organization for using Mattermost and contributing to the community--testing, bug reports, and conversations like this one, and the many you have started, are valuable and appreciated.

2. You can apply for an exception to non-profit licensing for the Enterprise Edition. There are many clubs that use the non-profit Enterprise Edition version and we're happy they do. Team Edition is "virtual office" where a team works together as trusted colleagues. It means people can walk anywhere they want, and move the furniture if they choose. Enterprise Edition is a "virtual campus", where you sometimes need locks on the doors, or even keycards to move from building to building. The group of 300 people you're describing doesn't sound like the intended audience for "Team Edition". If you want $568/month of value for $4.16/month (non-profit license costs $50/year), just fill out a form to find out . You're also more than welcome to fork and maintain your own version if you like.

3. If you're running an open source community, that's fine for a non-profit license as well, plus we're talking to opensource.com right now about potentially offering a free, hosted, multi-tenant Enterprise Edition version of Mattermost for open source projects.

4. Yes, I agree 100% the inability to restore archived channels from the UI in any edition of Mattermost totally sucks. I have proposed this change several times, I've even offered a design and a ticket, and I've been shot down every single time because the UX team wants to design things a certain way, and my proposal is in limbo right now. I'm a core committer to the project, and while I'm unhappy about the state of the feature I believe should be part of the product, I support the process of the design team, which has to balance many priorities--including other designs I propose that sometimes to do implemented.

5. Per community guidelines, which you and I have discussed in other tickets, I need to ask this ticket be closed since it's not a bug (simple test: if you wrote the code for the entire product, would you consider what you're seeing as an unintentional outcome?). I've had to close my own tickets before (see 4 above) and have done so, it's just how our process works. Discussion after the ticket is closed is absolutely welcome.

@danilvoe just curious, what country are you in?

• We have resellers to help you with a bidding and procurement process if you'd like to use Enterprise Edition. We have multiple public sector organizations as customers. You're of course more than welcome to fork as well.

[danilvoe]

@it33 Russian Federation.

[realrolfje]

I'll close this ticket per your request @it33, but please note that this strange and unintuitive user rights model baffles not just me, but all our 300 users. With a Channel Owner role, it is only logical to assume that the users can't just delete any channel.

@danilvoe, In your local fork did you get iPhone/Android push notifications going?

[it33]

Thanks @realrolfje, highly appreciated,

• I've shared feedback on Channel Admin with the product team. I agree it sounds confusing, if it's not being used I wonder why we show it, it does seem like a bug to me, but I'll defer to the feature owner for feedback. This is a new feature introduced recently. Thank you for finding this!

Thanks @danilvoe, I'll see if we have anyone from the Mattermost community who could be of service to your organization. Forks are highly welcome and we often get high quality Help Wanted projects from developers operating a fork.

Could you help me understand what "ITS" stands for?

This possibility is available in the ITS version of the Matternost.

I'm not familiar with the term.

[it33]

@realrolfje please hold on closing this ticket, I believe there is a bug here. I'll defer to @esethna to review.

[danilvoe]

@it33

Could you help me understand what "ITS" stands for?

There was not understanding in consequence of use https://translate.google.ru, there was in view of the version.

@realrolfje

In your local fork did you get iPhone/Android push notifications going?

Have not yet touched it. Most users use the client on Windows.
We plan to use our (self-hosted) service for push notifications, but for now, without specific technical solutions, there is a related project which also needs to be notified and it is desirable to use the same service for both projects.

[realrolfje]

Ok I'll keep the issue open. I hope you can convince your team that only Channel Admins can delete a channel.

@danilvoe I believe that for push notifications to work, the client may need recompiling/redistributing too. I didn't get the react version of the client working on my development setup, it might prove to be a problem, but I'll save that discussion for another time.

[it33]

Thanks @realrolfje, actually, I think the bug is that we should not be showing Channel Admin as a role in Team Edition. Team Edition is for teams, having a bunch of permissions to understand and configure seems detrimental to the majority of teams.

[realrolfje]

I was afraid you'd say that. Apart from refering to your documentation, how many Team Edition users are reporting back to you that the user interface is too complex? It's much simpler than Facebook for instance.

At this point we are doing more work (hosting, updating, monitoring, certificate rotation, backups, teaching people how to report bugs to contribute to open source, running the beta of the mobile app, running the matterbridge) because we (I) believe in the power of open source and collaboration. Team edition struck us as "you're on your own, but with a little work you can do it".

I am a bit dissapointed right now that my report/contribution leads to removal of a feature instead of fixing it.

Before your team removes this, please consider that by removing features, your Team Edition gets less and less interesting for starters compared to Slack, your major competitor and clear UI inspiration. Our 300 user organization has generated 4GB of data so far. We could have easily used Slack, but we chose Open Source and Self-Hosting. Slack would have been much easier, and have more features, and less quirks. (Also note that the free version of Slack has 2FA ;-) )

We chose Open Source because we expected return on investment. We chose Open Source because we don't trust a for-profit company offering to host our data for free. We'd like to help you make Mattermost be better, cooler, without quirks, without the need to dumb it down.

[realrolfje]

An argument which may be more in line with the reasoning of the documentation: Providing each user with a "Delete Channel" option right next to the "Leave Channel" option makes it harder for the inexperienced user (as demonstrated in my original writing in this issue, this is a problem for us). Which is a strong case for keeping the "Channel Admin" role, so that you can remove the "delete channel" option for normal users, and only present that to the more educated admin.

So by removing the "Channel Admin" role, you would make it harder for us, not easier.

[it33]

Hi @realrolfje,

Sorry, I think we're back to the feature versus bug discussion. While that discussion is welcome in feature proposal forum, it's distracting for the community that uses GitHub issues as designed--which is for bugs and Help Wanted tickets.

Also, it's modeling incorrect behavior. if features discussions aren't happening in the feature proposal forum, then we've scattered the conversations and it scatters our community.

I was hoping we could keep your ticket open to apply the correct fix--you did discover the bug, which seems to have been added a couple of months ago--but my concern is that the thread is now too long and too muddled, making it harder for a community member to come along and make the proper change.

I've opened a discussion in the feature proposals channel of our community server to welcome further discussion among 229 community members in the channel.

I've also opened a new ticket to fix the obvious bug we're discussing.

Now that those are done, could I ask your help to close this ticket so that we have a clean separation of the two topics?

[realrolfje]

I'll further "distract the community" with a workaround which enables them to protect their channels in Mattermost: https://rolfje.wordpress.com/2017/10/26/mattermost-delete-channel-fixed/

I hope this solves at least part of the problem for users who are as puzzled as I am over this thought process.

[GiancarloJSantos]

Another fix . Hope this help

http://www.akitaonrails.com/2016/08/12/hacking-mattermost-team-edition

[ArjonBu]

Is there a fix for the latest version? I can't believe a very critical feature like this is not included in the open source version....

[it33]

Hi @realrolfje,



It’s been over two years since this thread was started and I’m highly appreciative of your feedback and other folks who have contributed. The Mattermost open source project has grown a lot since then, the pace of innovation continues to accelerate, and it’s thanks to the continual engagement by users and contributors from our community.


One minor change related to this ticket is that “Delete Channel” (which was always a soft delete) was replaced by “Archive Channel” a while ago in the UI. I hope this now more accurately portrays the function of the system—Mattermost’s user experience is “open by default”.

A user experience that is open by default means there is a default to openness, transparency and accountability over control. The concrete example is that teammates are trusted to be smart and act with good intentions and therefore anyone can create, update, join, leave, read from, write to and archive public channels.


That’s the setup we’ve seen work really well for teams at the start of their journey—when people they work with are “teammates”. Teammates help each other out, they collaborate, if someone has a typo in a channel name, or people are creating many related channels where naming isn’t consistent, by default anyone can go in and update things—like an open Google Doc shared among colleagues. Things move quickly, transparently and collaboratively.

That’s the design of Mattermost Team Edition—which is an open messaging platform across web, mobile and PC with archiving, search and integrations (compatible with Slack webhooks) plus custom emojis, emoji reactions, animated GIFs and many bells and whistles end users want.


Teams can collaborate in all sorts of ways on the platform, and often we’ll see developer teams start implementing a number of Mattermost Chatops workflows beyond general collaboration.

For those interested, here’s a 15-minute video of deploying the open source Mattermost Team Edition on Azure, importing a Slack team, and walk through many of our core open source features: https://www.youtube.com/watch?v=AKqHWqrAgpk

For many teams, the open source platform will be all they want or need, and that is important to “Mattermost, Inc” as a business because it creates the user community around the open source project that’s propelling us to ever greater levels of popularity, recently just passing Jenkins, Vault, Puppet and Docker in GitHub star count.

Where Mattermost makes its money is in “beyond the team” scenarios—when Mattermost has become so popular within an enterprise that now teams of teams want to use the system with hundreds, thousands and even tens of thousands of users.

This is when Mattermost is no longer hosted by the original developer who spun up our binary/Docker image/K8 deployment and moves to hosting by Departmental or Central IT.

The good news for end users is Mattermost is becoming official—IT typically upgrades from the open source Mattermost Team Edition to the commercial Mattermost Enterprise Edition for SAML SSO, AD/LDAP sync, and other features like high availability, Enterprise Information Archive (EIA) integration, eDiscovery and other compliance features. The mixed news for end users is that IT is typically cutting back on the “open by default” user experience and replacing it with a permissions-based system designed to scale Mattermost to very large organizations—as an example, creating, renaming and archiving channels now can only be done by certain people.

We align our offerings and priorities based on the needs of a team or enterprise:


The priorities of the open source Mattermost Team Edition are the needs of the end user, the team and “open by default” experience where a team can rapidly explore and configure Mattermost to meet their needs. For some teams, all their needs are met by the Team Edition and they become advocates and promoters.

Example: https://news.ycombinator.com/item?id=21817975

The priorities of the commercial Mattermost Enterprise Edition are to serve managers, system admins and IT organizations in delivering a collaboration service that meets both end user and team needs as well as the control and compliance needs of the enterprise. The commercial version of Mattermost produces revenue for "Mattermost, Inc." and funds further development of both open source and commercial solutions.

It’s with this intention and context that the ability to restrict end users from archiving channels--to reduce the freedom and trust of a team--still seems like it belongs in Enterprise Edition. 



That said, your other ticket on password length restrictions did get moved from Enterprise Edition to Team Edition if that’s helpful: https://github.com/mattermost/mattermost-server/issues/5935#issuecomment-566871363

[realrolfje]

Thank you for moving the password length restrictions to the Team Edition, that really helps in adding security to the system.

As you can see by user contributions with fixes for the delete/archive channel in this thread, we are not sharing the same view on wether any user should be able to archive a channel. In a bigger community (like the one I am running Mattermost for), there will be disputes and misbehaving users who delete/archive channels just because they are emotional, or by accident. In my particular instance, I have a warning system installed and I will un-archive these channels with a database query when this happens but it is not ideal.
What you are saying is that in an Enterprise setting, there is less trust in the user. In my experience, that is exactly the other way around; in an Enterprise setting, we have selected, paid for colleagues who are expected to behave professionally. In an open-source setting anybody can (and should be able to) join, and sometimes that attracts people with wrong intentions.

[alexanderadam]

In my particular instance, I have a warning system installed and I will un-archive these channels with a database query when this happens but it is not ideal.

Are you using something similar to the trigger that was mentioned on AkitaOnRails?

Question: Is there some up to date documentation/wiki where people share scripts like this or similar hacks?

It would probably help others having the same problem.
I mean it seems that most people, who are administrating Mattermost instances, agree on this anyway (even if the folks at Mattermost, Inc. are not), so this might be the reason why people are complaining and finding various solutions for the problem (1, 2, 3, 4, 5, 6, 7, …).

[realrolfje]

Oh that AkitaOnRails solution is wonderful! Thanks for the tip!

I was using a query to detect new deletes, and post those events to a private admin channel. When such an action happens, I manually go in to check if it is a valid deletion and I undelete the specific channel manually with an update query.

I have a number of queries on the Postgres db set up to post alerts in the admin channel, and I have added all admins to that channel so they can get alerts without having to open the admin settings screen.

I also have munin running on that machine which will post "disk full" and other stuff to the admin channel when needed.

[realrolfje]

For any Open Source product with an Enterprise version it is hard to decide which features need to go where. The most important reason is that there are no "Enterprise people" and "Open Source people". There are just "people".

[it33]

Thanks @realrolfje, FYI, I loved this Hacker News comment: https://news.ycombinator.com/item?id=21824219

p.s. we haven't run into the issue 6320 (users archiving channels), for exactly the reasons @it33 described in the issue report. He didn't explain it well, but permissions is a complex rathole, un-archive is a simple workflow for admins and if there's continued abuse, just ban the user.

https://news.ycombinator.com/item?id=21824219

I agree asah is way more concise than I was. Simplifying explanations is something I need to work on. Thanks asah 🙌!!

[it33]

Just to add, I hope I am making progress from 10 months ago on being too marketing-y:

FYI this comment comes across as very unnatural marketing through 'community engagement', hijacking the top comment. This is HN not some business Bros you can lull to market with 'journey' fluff. Please don't abuse HN.

I love this comment as well. It's on my to-do list to print a T-shirt with this on it.

https://news.ycombinator.com/item?id=19104350

[rolfchess]

It is great to see you have a customer not running into this problem, but the posters to this issue and I clearly have. "Permissions is a complex rathole" is not a valid reason for having a feature in Team Edition but not in Enterprise edition.

A user archiving a channel effectively makes the service unavailable to other users until a system admin finds the time to detect and fix it. Assigning a channel an owner and make him/her admin of it is a well accepted solution that delegates it to the correct user and makes the system more scalable and more resilient against abuse without admins having to constantly monitor abuse.

[alexanderadam]

It is great to see you have a customer not running into this problem, but the posters to this issue and I clearly have. "Permissions is a complex rathole" is not a valid reason for having a feature in Team Edition but not in Enterprise edition.

For me neither and obviously not for the users that are commenting in this issue or the ones I mentioned before.

Even the explanation "but permissions is a complex rathole, un-archive is a simple workflow for admins and if there's continued abuse, just ban the user" is pretty strange.

Because if archiving would simply require the same role as deleting, everything would even be simpler than having to "just banning the user" or applying rules on nginx or postgresql. :laughing:
I can hardly imagine something that is worse than the "current rathole". :wink:

So I guess I fully understand this user (newsat13) as well:

[it33]

Updating title per: https://news.ycombinator.com/item?id=21822740

Very open to continued feedback here, want to make sure people understand the specific issue being discussed:

Open to feedback on accuracy of updated title.

[rolfchess]

I'd change the title to "non-admins can archive any public channel". Shorter is better.

We haven't mentioned private channels here. We are talking about begrudged users who are part of an open channel discussion and (by accident or otherwise) hit the "archive" button (which to them is "delete" because they can not undo it, only an admin can).

[it33]

Thanks for the feedback. Could I ask your help to share more?

I'd change the title to "non-admins can archive any public channel". Shorter is better.

a) With this title change is the proposal that a non-admin who creates a public channel be prevented from archiving the channel they just created?

b) If so, what happens if a user creates a channel by accident, or unknowingly creates a duplicate of an existing channel, creating confusing?

We haven't mentioned private channels here.

c) In what way would you see private channels functioning differently from public channels in the context of the title?

[EdgarSedov]

Hi. Sorry for my emotional reply, but reading this thread is so painful.
U're acting like open-source product with enterprise version. Stop using "Team version" -it's just a name. Main reason all people are here are because product is good and open-source. Nobody cares about some strange-maked "team" philosophy.
Since u're acting like an open-source product it seem really ugly that u're just closing PRs with features from users. It's a COMMUNITY VERSION. Why u restrict community from adding features they want based on some strange "pholosophy"? So imagine one day me and my team make pull request with almost all features u have in enterprise edition. U'll simply shut it down, because u want to make money, and not the good open-source product. Otherwise you would gladly accepted PR's with permissions system to an open-source version.