Email service

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. false still 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 email inside 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 from.hbs and subject.hbs which are copied to the corresponding fields of the email. That is, for our example email template we can provide a Spanish translation by creating a folder es inside it with the corresponding localized templates.

`- email/
   `- html.hbs
   `- text.hbs
   `- es/
      `- html.hbs
      `- text.hbs
      `- from.hbs
      `- subject.hbs

If no translation is requested, the email contents will be used.


It’s up to the service using the email service to ask for the localized versions of the email.