The platform provides a service for sending emails. That service may be used by other services that need to reach users via email.The emails to be sent can be created by the service’s user or may use already defined templates. This allows the developer or the administrator to not need to define similar or equal emails more than once. Localized versions for such templates are also an option. All the features provided by the email service are supported by the underlying library nodemailer. Check it out if you need something that’s not explicitly supported by this service.
Configuring the service
The service is configured via the
wac.ini file as usual. It contains a top-level entry named
[mailer] that holds the service’s details.
There is one mandatory option to be provided:
host, which identifies the SMTP host:
The host (name or IP address) of the SMTP server.
The username for authenticating against the SMTP server.
The password to use for the given username.
The SMTP port to use (defaults to 587)
Whether to use TLS or not when talking with the SMTP.
falsestill allow STARTTLS (defaults to false).
Whether to use a connection pool or not (defaults to false)
A forced From: address, ignoring each email’s one (defaults to the one given in the email object)
Currently, only SMTP/S is supported
Creating new templates
Templates use the handlebars syntax. It’s an easy and intuitive replacement syntax. Just wrap your items to be replaced with
}} and you’re ready to go. Please take a look at provided template and website to learn more about it.
To have a template ready to use, please drop it in a new folder inside
templatePath (variable under
[meetings] entry) . For instance, if you want to add a new template for sending emails for meetings, you can create a new folder called
templatePath and copy there your template files.
Template naming rules
Template must adhere to strict but simple naming rules. As the email service allows to send both plaintext and HTML versions of an
email, there has to be a template for each of those versions. The plaintext one is mandatory and the HTML is optional. For the plaintext version, the file must be named
text.hbs. The HTML template, is named
html.hbs. If both templates are found, the email will have one alternate part for each of the versions. For example, this might be the real contents of
templatePath/ `- email/ `- html.hbs `- text.hbs
Localization of templates
There is also support for localization of templates. From the administrator point of view it is as easy as creating a subdirectory in
the template directory named after the locale to be used. Inside this folder we can also include two more files
subject.hbs which are copied to the corresponding fields of the email. That is, for our example
es inside it with the corresponding localized templates.
templatePath/ `- email/ `- html.hbs `- text.hbs `- es/ `- html.hbs `- text.hbs `- from.hbs `- subject.hbs
If no translation is requested, the
It’s up to the service using the email service to ask for the localized versions of the email.