Additionally if more flexible naming is required for the emailed reports, there exists an additional syntax that specifies a "naming" function. In this case use Mez:emailAttach which also takes these naming functions as arguments as in the excerpt below. The naming function is a 0-arg function that returns a string that will be run when the report is generated/emailed. A function can be specified for each report, or the same function can be specified multiple times. A single report "pair" can be specified or multiple.
To change the layout, images or colours of the e-mail for e.g. custom branding purposes, a final enum parameter can be added to the Mez:email or Mez:emailAttach BIFs to specify a custom (html) e-mail template. The enumerated type is EMAIL_TEMPLATES, with the specified enum member the html file name (without the extension), as included by the developer under the web-app/email-templates directory. Images for this template is to be included under web-app/images, and prefixed by "cid" in the html.
Please note that it is not mandatory to have the email-template folder. If one is not included the original default email template in service will be used to send messages.
To override this behaviour you can include just one template called "default.html" which will then be used for all the mails instead of the original "default" template. Just including the file will enable the behaviour without you having to explicitly mention the template when the email syntax is used. More customization will require you to indicate the template you want to use via above mentioned enumeration.
Please refer to the default e-mail template as an example or starting point for your custom template: email_template.html. Note that it contains ${subject}, ${body} and ${applicationInstanceName} placeholders that are replaced at runtime. In essence these placeholders should always be standard and included in any variation of custom template you introduce.
Add Comment