Customization of email templates
-
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.htmlThe contents are all templating "code". Not sure if it's wise to make those editable.
-
-
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
.rpmnewwill 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/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". -
@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.) -
@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.
-
@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?
-
