Notifications Service Configuration

Introduction

The notification service is responsible for sending emails to users informing them about events that happened. To do this, it hooks into the event system and listens for certain events that the users need to be informed about. As an example, when a user is added to a share, a notification email will be sent to the user.

  • The notifications service does not start automatically and must be started manually. For more details see the Start Infinite Scale section.

  • The reason for excluding the notifications service from autostart is, that the service will block starting up all other services if the NOTIFICATIONS_SMTP_SENDER environment variable is not set. The value can be the real or a placeholder email address for startup testing purposes.

Default Values

  • Notifications listens on port 9170 by default.

Email Notification Templates

The notifications service has embedded email text and html body templates.

Email templates can use the placeholders {{ .Greeting }}, {{ .MessageBody }} and {{ .CallToAction }} which are replaced with translations when sent, see the Translations section for more details. Though the email subject is also part of translations, it has no placeholder as it is a mandatory email component.

Depending on the email purpose, placeholders will contain different strings. An individual translatable string is available for each purpose, to be resolved via the placeholder. The embedded templates are available for all deployment scenarios.

template
  placeholders
    translated strings <-- source strings <-- purpose
final output

In addition, the notifications service supports custom templates. Custom email templates take precedence over the embedded ones. If a custom email template exists, the embedded templates are not used. To configure custom email templates, the NOTIFICATIONS_EMAIL_TEMPLATE_PATH environment variable needs to point to a base folder that will contain the email templates and follow the Templates Subfolder Hierarchy. This path must be available from all instances of the notifications service, a shared storage is recommended.

{NOTIFICATIONS_EMAIL_TEMPLATE_PATH}/templates/text/email.text.tmpl
{NOTIFICATIONS_EMAIL_TEMPLATE_PATH}/templates/html/email.html.tmpl
{NOTIFICATIONS_EMAIL_TEMPLATE_PATH}/templates/html/img/

The source templates provided by Infinite Scale you can use and adjust are located in the following base folder email / templates with subfolders text and html.

Templates Subfolder Hierarchy

templates
│
└───html
│   │   email.html.tmpl
│   │
│   └───img
│       │   logo-mail.gif
│
└───text
    │   email.text.tmpl

Custom email templates referenced via NOTIFICATIONS_EMAIL_TEMPLATE_PATH must also be located in a subfolder templates/text and templates/html and must have the same names as the embedded templates. It is important that the names of these files and folders match the embedded ones. The templates/html subfolder contains a default HTML template provided by Infinite Scale.

When using a custom HTML template, hosted images can either be linked with standard HTML code like:

<img src="https://raw.githubusercontent.com/owncloud/core/master/core/img/logo-mail.gif" alt="logo-mail"/>

or embedded as a CID source like:

<img src="cid:logo-mail.gif" alt="logo-mail"/>

In the latter case, image files must be located in the templates/html/img subfolder. Supported embedded image types are png, jpeg, and gif. Consider that embedding images via a CID resource may not be fully supported in all email web clients.

Translations

The notifications service has embedded translations sourced via transifex to provide a basic set of translated languages. These embedded translations are available for all deployment scenarios. In addition, the service supports custom translations, though it is currently not possible to just add custom translations to embedded ones. If custom translations are configured, the embedded ones are not used. To configure custom translations, the NOTIFICATIONS_TRANSLATION_PATH environment variable needs to point to a base folder that will contain the translation files. This path must be available from all instances of the userlog service, a shared storage is recommended. Translation files must be of type .po or .mo. For each language, the filename needs to be notifications.po (or notifications.mo) and stored in a folder structure defining the language code. In general the path/name pattern for a translation file needs to be:

{NOTIFICATIONS_TRANSLATION_PATH}/{language-code}/LC_MESSAGES/notifications.po

The language code pattern is composed of language[_territory] where language is the base language and _territory is optional and defines a country.

For example, for the language de, one needs to place the corresponding translation files to

{NOTIFICATIONS_TRANSLATION_PATH}/de/LC_MESSAGES/notifications.po


For the time being, the embedded ownCloud Web frontend only supports the main language code but does not handle any territory. When strings are available in the language code language_territory, the web frontend does not see it as it only requests language. In consequence, any translations made must exist in the requested language to avoid a fallback to the default.

Translation Rules

  • If a requested language code is not available, the service tries to fall back to the base language if available. For example, if the requested language-code de_DE is not available, the service tries to fall back to translations in the de folder.

  • If the base language de is also not available, the service falls back to the system’s default English (en), which is the source of the texts provided by the code.

Default Language

The default language can be defined via the OCIS_DEFAULT_LANGUAGE environment variable. See the settings service for a detailed description.

Sending Grouped Emails

The notifications service can initiate sending emails based on events stored in the configured store that are grouped into a daily or weekly bucket. These groups contain events that get populated e.g. when the user configures daily or weekly email notifications in his personal settings in the web UI. The notification settings are only visible in the web UI when enabled via the enironment variable FRONTEND_CONFIGURABLE_NOTIFICATIONS. If enabled and a user does not define any of the named groups for notification events, no event is stored.

Grouped events are stored for the TTL defined in OCIS_PERSISTENT_STORE_TTL. This TTL can either be configured globally or individually for the notification service via the NOTIFICATIONS_STORE_TTL environment variable.

Grouped events that have passed the TTL are removed automatically without further notice or sending!

To initiate sending grouped emails like via a cron job, use the following command:

ocis notifications send-email

Note that at least one option, --daily or --weekly, must be provided. Both options can be used together.

Storing

The notifications service can use a configured store via the global OCIS_PERSISTENT_STORE environment variable.

Note that for each global environment variable, an independent service-based one might be available additionally. For precedences see Environment Variable Notes. Check the configuration section below. Supported stores are:

Store Type Description

memory

Basic in-memory store. Will not survive a restart.
Usually the default for caches. See the store environment variable for which one is used.

nats-js-kv

Stores data using key-value-store feature of NATS JetStream.
Usually the default for stores, see the store environment variable for which one is used.

redis-sentinel

Stores data in a configured Redis Sentinel cluster.

noop

Stores nothing. Useful for testing. Not recommended in production environments.
The notifications service can only be scaled if not using the memory store and the stores are configured identically over all instances!
If you have used one of the deprecated stores of a former version, you should reconfigure to use one of the supported ones as the deprecated stores will be removed in a later version.
Store specific notes

  • When using redis-sentinel:
    The Redis master to use is configured via e.g. OCIS_PERSISTENT_STORE_NODES in the form of <sentinel-host>:<sentinel-port>/<redis-master> like 10.10.0.200:26379/mymaster.

  • When using nats-js-kv:

    • It is recommended to set OCIS_PERSISTENT_STORE_NODES to the same value as OCIS_EVENTS_ENDPOINT. That way the cache uses the same nats instance as the event bus. See the Event Bus Configuration for more details.

    • Authentication can be added, if configured, via OCIS_CACHE_AUTH_USERNAME and OCIS_CACHE_AUTH_PASSWORD.

    • It is possible to set OCIS_CACHE_DISABLE_PERSISTENCE to instruct nats to not persist cache data on disc.

Event Bus Configuration

The Infinite Scale event bus can be configured by a set of environment variables.

  • In case of an orchestrated installation like with Docker or Kubernetes, the event bus must be an external service for scalability like a Redis Sentinel cluster or a key-value-store NATS JetStream. Both named stores are supported and also used in Caching and Persistence. The store used is not part of the Infinite Scale installation and must be separately provided and configured.

  • Note that from a configuration point of view, caching and persistence are independent of the event bus configuration.

Note that for each global environment variable, a service-based one might be available additionally. For precedences see Environment Variable Notes. Check the configuration section below.

Without the aim of completeness, see the list of environment variables to configure the event bus:

Envvar Description

OCIS_EVENTS_ENDPOINT

The address of the event system.

OCIS_EVENTS_CLUSTER

The clusterID of the event system. Mandatory when using NATS as event system.

OCIS_EVENTS_ENABLE_TLS

Enable TLS for the connection to the events broker.

OCIS_INSECURE

Whether to verify the server TLS certificates.

OCIS_EVENTS_AUTH_USERNAME

The username to authenticate with the events broker.

OCIS_EVENTS_AUTH_PASSWORD

The password to authenticate with the events broker.

Configuration

Environment Variables

The notifications service is configured via the following environment variables. Read the Environment Variable Types documentation for important details. Column IV shows with which release the environment variable has been introduced.

404: Not Found

  • 8.2.0

404: Not Found

YAML Example

  • 8.2.0

404: Not Found