Cloudron Forum

@girish said in Updating from v7.1.4:

@cpa We moved out of AWS a while ago. Looks like older version of Cloudron is caching the old release. To fix:

• Delete the file /home/yellowtent/platformdata/update/updatechecker.json
• systemctl restart box
• Now , Settings -> Check for updates and then try to update

Facing the same issue here, and this resolved it for me.

And now I realized that my installation was multiple versions behind (like at least half-a-year behind), despite having weekly auto-update enabled. I'm afraid there could be more people like me who didn't check and didn't know it is stuck on 7.1.4.

@girish It's working on my end (only tried notification emails).

I see that you have even added a backup folder, great work. Thank you so much for this.

@girish It's definitely better than nothing, right? Though I don't think this is a long term solution, because upgrades can be automatic (scheduled), also the chance that someone new may be surprised to find their customizations overwritten is quite high.

Maybe we can settle with option c atm, and let's see if we can get option a later?

@girish said in Customization of email templates:

The contents are all templating "code". Not sure if it's wise to make those editable.

At least we should give those who need to edit them a choice? And all this "code" is documented, like plugin API.

Given my own investigation above, I see a few ways going forward:
a) either we can convince mattermost devs to add an option to the location of custom templates, which overrides default templates (it's not a good practice to modify application code directly anyway);
b) or cloudron can copy the templates from /app/code to /app/data during initial setup, create a symlink, and provide a mechanism to do a diff during upgrades;
c) just like option b but without the upgrade mechanism. Instead, customizations are overwritten during each upgrade. Admins are responsible for backing up their customizations. This is somewhat similar to the current approach of mattermost, I believe.
d) Of course, the other alternative is that we will not have this capability, but then it is a real blocker for anyone like me who wants to customize the templates. (For me it's for security reasons, I need to remove the message body. For now, I have to disable email notification as a whole.)

https://docs.mattermost.com/upgrade/upgrading-mattermost-server.html#id2
It seems to me that the official upgrade guide simply asks the server admin to clear the folder (including templates) and then unpackage the new tarball. This is probably how it gets "overwritten".

I'm not sure what the warning means either. I haven't deployed mattermost outside of cloudron. But I guess, it is probably up to the package manager to decide how to handle the difference? E.g. in RHEL-derivatives, if RPM contains a new version of an locally-modified config file, a new copy with extension .rpmnew will be created. But in the case of mattermost, all deployment documentation seems to refer to tarball installation only, and in that case it is probably up to the tar command used whether to overwrite the local changes?
In that case, I guess cloudron needs to implement something like the above rpmnew solution.

https://docs.mattermost.com/configure/email-templates.html
According to the official documentation, customization of email templates is done by modifying the HTML files inside templates folder directly.

However, in the case of Cloudron, these files are in the code folder, which is read-only. I wonder if it's possible, maybe in a future release, to modify these templates? Is it possible to configure this from the data folder?