EE: Data retention and prune/reset/clear channel content options
For compliance, add the ability to delete specific messaging entries from the user interface, including:
- Clear a specific channel of all its content
- Delete all posts from a specific user
- Delete all posts from a specific user in a specific channel
- Delete all posts from/before/after a specific date
- Configure a data retention time
This feature ships in BETA with v4.3 on October 16th.
I work for an NGO that does almost all it's internal communication through a self-hosted Mattermost instance. We fear that a breach of our server can have damaging effects, similar to the effects of the Podesta email leak. We try to minimize the consequences of a breach as much as we can, and minimizing the amount of information we have to protect helps a lot. This means that we can greatly benefit from the possibility to (automatically) delete messages after a certain time.
This is sorely needed. Especially for cleaning up bot messages...I have to segregate human and bot channels because the human conversations would get lost after a few days of jenkins results.
Dan Farmer commented
As someone who works with sensitive data that has legislative requirements foisted on me (not like I want them, but I have no choice!), not having this is a real burden.
The cron hack below doesn't help unless it's officially supported feature, but if someone cut-n-pastes the wrong data into MM that I need to kill off, I'm stuck.) This is preventing me from using this for full production services.
To respond to @mattermost.org, I'm using a bot to push on a spécific channel every single compilation of my ci projects(sucess/error purposes). It would be nice to clear the past 6 months compilations messages
mathew murphy commented
I was going to spin up a Mattermost instance. The lack of this feature made me decide not to.
Samuel Leslie commented
I work as a SysAdmin in the finance sector and this is definitely a highly desired feature. I suspect this is true of many industries working with sensitive information from a legal liability point-of-view.
However, it's also of value as a mechanism for discouraging users from using Mattermost as persistent storage. Obviously, for many companies this is fine, but in finance we want to use Mattermost strictly for "transient" communications. Important client information should be more formally documented elsewhere. Enforcing, e.g. a 6 month retention can serve as an effective means to ensure users don't start treating their Mattermost history as a huge log of arbitrary info.
Shawn C commented
I'm currently trying out Mattermost at the defense contractor I work for as an alternative to Skype/Lync, and one concern that keeps coming up repeatedly is retention policies. IT and others aren't so pleased about the fact that Mattermost doesn't have any (official) way to discard message history after a set amount of time. While I disagree with the need to do so on a personal level, Mattermost faces opposition from the decision-makers here because of the lack of automatic pruning. Company policy, as it were.
People are otherwise quite pleased with the platform so far and are excited to not have to deal with the shortcomings of our existing team collaboration tools. It's a shame that this is a major obstacle to adoption.
Thanks for everyone's feedback on this feature.
There's about 17 people who've contributed votes so far, which means the average is a little over 2 votes per person, which is about 20% of the 10 votes per user available in the feature idea forums--so somewhat significant.
Just curious, we haven't heard this request very often and we're wondering if there's a pattern around industries looking for this.
Would votes be open to sharing which industry they're coming from? For example: government, finance, legal, large enterprises, etc.
Just trying to understand if this is broad need or something specific to a subset of users.
thank you @anon for creating code to handle this feature request. Has the change been approved and commited to the Mattermost platform? Thanks.
I'm not a huge fan of this feature request, as philosophically I agree that all message history should be retained and searchable as a kind of lazy knowledge base.
However, in corporate environments where there might be strict policies relating to message retention, some may be forced to accept limited message history in order to still reap the benefits of chatops style automation and collaboration.
So, until this feature is accepted into the pull request list and fully implemented, anyone inclined to patch and build mattermost themselves might be interested in the simple hack included within the commit referenced here:
1.) Permanently deleting all messages older than 5 days would require a cronjob executing the following command (using flags enabled through the previously referenced commit)
e.g., /opt/mattermost/bin/platform -permanent_delete_posts -duration_retained="120h" -confirmation_override
2.) This is possibly more of a hack than simply running a cronjob with a postgresql/mysql script to delete posts from the table. However, at least the above approach handles db authentication, etc, and is approaching consistency with mattermost's other -permanent_delete_team/user commands.
3.) Remaining steps to fully realize this feature: add unit test cases and permanently delete any file uploads older than X days
4.) Another approach might be to "soft delete" posts, simply hiding them from view within the web & mobile interfaces. However for companies that don't want "chat logs" to be discoverable, then a "permanent delete" approach is probably the most appropriate approach.
this is a requirement for my team as well. we need a way to automatically delete entries older than X number of days too. a full record of every past conversation is the reason we can't use mattermost. need the ability for past conversations to be forgotten/deleted/pruned.
i agree especially with the data retention, Slack have included this feature in their plus package. My boss would like us to clear messages older than X number of days. So it would be a required feature from his point of view