Use only one templating system for emails.

Historically, emails sent offline (alerts, questionnaires, etc) used a
different templating system from those sent by the website (e.g. login
emails), though the newer system was also being used for the site name
and signature of offline emails.

1 files changed, 0 insertions, 8 deletions

diff --git a/perllib/FixMyStreet/Cobrand/Zurich.pm b/perllib/FixMyStreet/Cobrand/Zurich.pm
index d31b1c84e..987f0bb67 100644
--- a/perllib/FixMyStreet/Cobrand/Zurich.pm
+++ b/perllib/FixMyStreet/Cobrand/Zurich.pm
@@ -587,14 +587,6 @@ sub admin_report_edit {
         #    2) setting $problem->whensent(undef) may make it eligible for generating an email
         #   to the body (internal or external).  See DBRS::Problem->send_reports for Zurich-
         #   specific categories which are eligible for this.
-        #
-        #   It looks like both of these will do:
-        #       a) TT processing of [% ... %] directives, in FMS::App->send_email(_cron)
-        #       b) pseudo-PHP substitution of <?=$values['name']?> which is done as
-        #       naive substitution
-        #       commonlib mySociety::Email
-        #
-        #   So it makes sense to add new parameters as the more powerful TT (a).
 
         my $redirect = 0;
         my $new_cat = $c->get_param('category') || '';