@robi It's not an issue with cloudron. So I guess as soon as there is a fix by Mattermost it will also land here.
The only action step from @nebulon and cloudron would be to add some tests for boards in future releases.
@aizat So, the first one is a bug in mattermost UI. You can see that when you do some actions in the channels UI alone, there are some errors in the browser console. More importantly, I am able to do those actions like unarchive via the CLI just fine.
@mtd-sales let us know if you have trouble importing/exporting via mattermost CLI. One thing is that you want the version of mattermost you are running now and the one on Cloudron to match. On Cloudron side, if you look at the https://git.cloudron.io/cloudron/mattermost-app/-/blob/master/CHANGELOG it will tell you the package version. Then, you can change the package version in the URL bar of your dashboard when installing an app (i.e click the mattermost app in App Store and then change the version field in the URL).
As for storing things in S3, I think you have to decide whether you prefer files stored externally or on the server itself. The main difference is with respect to backups. If on server, Cloudron will include them in the backup and restore will also work properly. But if it's in an external service, the backup won't include them and thus restore might be complicated. Like if you restore to a mattermost from a week ago, I am not sure how you roll back S3 storage to a week ago (especially, if you had deleted files in the middle). I guess the compromise you make depends on your use case.
@marcusquinn that plugin was simple 1 to 1 calls directly initiated from the Mattermost ui. For that we leveraged the existing (unfinished) WebRTC integration into Mattermost. Because of this the first version of kwmserver had an api that was compatible to Janus (which was a requirement to the native WebRTC back then).
Currently there is no direct integration of Meet into Mattermost. We simply have too few customers using Mattermost to warrant the invest ourselves, but there was external interest in doing something, for example at https://github.com/Kopano-dev/meet/issues/9.
Wow, what a horrible design for maintenance.
Thanks for finding it.
I'm not interested in editing the DB.
As long as I find where the files are, I can clean those up without removing the messages and references.
Looks like I found just that at /app/data/files/.
A visit via the new File Browser in the Cloudron App Config/Console easily finds the few large attachments.
Another thing I noticed is that MM generates preview and thumbnail images for some reason, which more than doubles the storage requirements for each image uploaded. Some of the generated preview images are larger than the original uploads 🙁
thank you for your replies. I found the error in a complete different field. A custom emoji crashed the bulk export. After deleting this I could perform the export as planned and the import to Cloudron worked as described in the documentation. Still thank you for your efforts.