Customization of email templates

[robi]

@girish said in Customization of email templates:

might get overwritten

This suggests there is some checking, perhaps a diff that happens during upgrades.

[girish]

@robi yeah, I thought maybe they were somehow smart about updating the templates but I couldn't find any more information .

[zypA13510]

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.

[zypA13510]

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".

[zypA13510]

@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.)

[girish]

@zypA13510 I am open to b or c. Obviously option a is ideal but may not be practical and/or we won't get the feature in the timeline we want it. Cloudron doesn't have a mechanism to do b i.e providing diff and it's unlikely to get this feature. So, we are left with c. Are you ok with updates overwriting the template files? I think it's fairly easy to make that change on the packaging side.

[zypA13510]

@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]

@zypA13510 I pushed a new package, can you please try?

[zypA13510]

@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]

@zypA13510 awesome, thanks for testing. The backup folder will only contain the changed files.