Customization of email templates

[girish]

Just checked the templates directory:

$ ls
cloud_trial_ended_email.html                        invite_body.html                               payment_failed_no_card_body.html
cloud_trial_end_warning.html                        license_up_for_renewal.html                    reached_user_limit_body.html
cloud_upgrade_request_email.html                    Makefile                                       remove_expired_license.html
cloud_welcome_email.html                            messages_notification.html                     reset_body.html
deactivate_body.html                                mfa_change_body.html                           signin_change_body.html
email_change_body.html                              over_user_limit_30_days_body.html              unsupported_browser.html
email_change_verify_body.html                       over_user_limit_7_days_body.html               unsupported_browser.js
email_footer.html                                   over_user_limit_90_days_body.html              verify_body.html
email_info.html                                     over_user_limit_support_body.html              warn_metric_ack.html
globalrelay_compliance_export.html                  over_user_limit_workspace_suspended_body.html  welcome_body.html
globalrelay_compliance_export_message.html          password_change_body.html
globalrelay_compliance_export_participant_row.html  payment_failed_body.html

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

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