• One message can be sent in more ways (e.g. according to the configuration of a user's account) or sent by a specific channel defined by notification type.
• Messages are saved into the database - there is a notification agenda available for the application administrator
• Sending messages can be disabled by configuration (e.g. for testing purposes)
• If the recipient of the given notification isn't entered (e.g. a blank email), a record of not sending the notification is done in the log with level information

A concrete implementation of the notification sender via email (a wrapping of the camel emailer). Emailer (or rather EmailNotificationSender) is also injected into the workflow engine in order to be able to turn off sending of notifications for testing purposes. It is also possible to send emails for a specific identity (recommended) by entering the user name instead of the recipient's (or sender's) email address.

The emailer can be configured via application.properties or application settings agenda. A functional testing emailer settings.

If you want to test some project specific feature with sending email you can use AbstractNotificationTest, this class allows you to set up your own SMTP server (port and etc.), the class allows you to add your own implementation of Observer, or it is possible to use this implementation: NotificationObserver with solved concurrent thread.

Currently, we provide support for sending sms messages from CzechIdM, but administrator must provide concrete implementation of sender for a particular sms gateway.

Notifications can include attachments. The only sender that supports sending attachment is the email sender now. It's possible to send them from backend only, and the sent attachments are not persisted automatically.

Senders are configurable thanks to interface Configurable via the standard application configuration. More than one implementation of notification sender for one notification type can be installed into CzechIdM. You need to configure, which one is to be used, when notification of a given type is sent. Sender with the lowest order is used as default. Core senders use order 0.

Feature notification's configuration disabled attribute was added. While sending notification, notification configurations are searched and IdM searches for suitabled ones. Firstly it searches for exact topic and level, if it did not find any, it continue search just with topic and even then if no notification configuration is found, notification will be send anyway. To this algorithm disabled option was added. So now if notification configurations are found, just these, which are disabled are not send:

1. search exact topic, level → if found, send just to not disabled ones and not continue. if not found continue with 2.
2. search just with topic for general notification configuration → if not found, send anonymously, if found, check if it not diasbled.

There are two items in notification's configuration detail: 'Recipients' and 'Redirect'.

In Recipients, you can add email addresses separated by comma. Notifications with this topic are sent to normal recipient (e.g. password is changed for John's identity → notification sent to John), and also it is sent to any other addresses specified in 'Recipients'.

Once the 'Redirect' option is selected, this means that notifications will only be sent to recipients specified in 'Recipients', at which point the 'Recipients' field becomes mandatory.