Notifications

iTop integrates a notification system linked to the life cycle of the objects. This allows administrators to define email notification rules when an object of a given class enters or leaves a specified state, when a new object is created, when an update occurs from the portal or when certain thresholds are reached.

The notification mechanism is divided in two parts:

Triggers define when notifications have to be sent. Example: when a ticket reaches the state “assigned”.
Actions define what will be done. In the current version of iTop, the only available kind of action consist in sending an email.

For a given trigger you can define several actions to be executed, and their sequence. Also, a given action can be executed by several triggers.

Use the link “Notifications” in the “Admin tools” menu to manage triggers and actions:

The “Triggers” tab displays all created triggers.
The “Actions” tab displays all Actions

Creating an action

Before creating a useful trigger, at least one action must be defined. Email actions are templates for formatting the messages to be sent, the define the content of the message as well that the subject, sender and recipients.

To create a new action, go to the “Actions” tab and click on “New…”. The following wizard appears:

The mandatory fields for an email action are:

Subject: the subject of the message. May be built dynamically by using placeholders as described herebelow.
Body: the body of the message. May be built dynamically by using placeholders as described herebelow. By default iTop sends all the messages with the MIME Type text/html for the body of the email, so you may put HTML tags to format the message.
From: this field contains a static email address. Note that some email servers will reject the message if the “from” address is not valid.

Defining recipients

The contacts to be notified in the “To”, “Cc”, and “Bcc” are defined by an OQL query. This allows to specify multiple recipients for the notification, like “all the contacts attached to a ticket” or “all the contacts on the impacted site”. (Refer to Object Query Language Reference for more information about writing OQL queries)

This OQL query must return a list of objects containing an email attribute, namely:

Contact
Person
Team

For instance, to notify all persons whose name starts with John, the To field can contain:

SELECT Person WHERE name LIKE 'John%'

The query can contain placeholders that refer to the current object for which the notification is being sent. The syntax is :this->attribute.

For example, to send a notification to the person who is the “caller” of a ticket, the To field will contain:

SELECT Person WHERE id= :this->caller_id

If the list returned by the query is empty no email will be sent.

To notify all the Persons attached to the Ticket (i.e. all the Persons in the “Contacts” tab) the OQL query to be used as recipients (either To, CC or Bcc) is the following:

SELECT Person JOIN lnkContactToTicket AS L ON L.contact_id =
Person.id WHERE L.ticket_id = :this->id

Message contents and placeholders

The “Subject” and “Body” parts can be build dynamically by using placeholders. The syntax to be used for such placeholders is $xxxx$ .

The placeholders available for the recipient queries (TO, CC, BCC…) differ from the placeholders available for the message parts (subject, body).

There are several types of placeholders:

$CONSTANT$ refers to a fixed value named constant.
$this->function()$ refers to a built-in function executed within the context of the object that triggered the action.
$this->attribute$ refers to the field attribute of the object that triggered the action.
$this->representation(attribute)$ refers to a built-in representation of the field attribute of the object that triggered the action. Ex: $this->html(name)$ .

Those various types are described in details hereafter:

Fixed placeholders

Placeholder	Meaning
$APP_URL$	URL of the iTop application.
$MODULES_URL$	Root URL of the modules (e.g. `$APP_URL$/env-production`).

Built-in function placeholders

Placeholder	Meaning
$this->name()$	The name of the current object
$this->hyperlink()$	The url to access the current object in iTop
$this->hyperlink(portal)$	The url to access the current object in the iTop portal

Attribute placeholders

Function	Description	Supported types of attributes
$this->attribute$	The plain text representation of the value of the attribute	any
$this->id$	The id of the current object (there is no such attribute at that time)

Though there is no 'id' attribute', the placeholder $this->id$ is available to represent the iTop internal identifier.

Link set attributes: the very standard syntax $this->attribute$ returns a list of names (separated by a new line character, see the note below).

Attribute representations

Function	Description	Supported types of attributes
$this->html(attribute)$	The HTML representation of the value of the attribute	any
$this->label(attribute)$	The localized representation of the value of the attribute. The language is the language of the user currently logged in	any (only make sense for AttributeEnum)
$this->head(attribute)$	Plain text of the latest entry in the case log	AttributeCaseLog
New in iTop 2.0.3: $this->head_html(attribute)$	HTML formatted representation of the latest entry, whereas $this->html(attribute)$ returns an HTML formatted representation of the whole case log (you can apply your own CSS styling to make it beautiful).	AttributeCaseLog

The body of the message is in HTML. In HTML, newline characters are displayed as white spaces. Therefore, placeholders giving plain text would be displayed on one single line. The solution is to surround the placeholder by a tag <pre>. Examples: <pre>$this->head(public_log)$</pre>, <pre>$this->ci_list$</pre>

Example: UserRequest

Assuming that a notification is triggered when assigning a User Request, the body of the message could be:

<html>
<body>
<p>Dear $this->html(agent_id),</p>
<p>The ticket $this->ref$ has been assigned to you.</p>
<hr>
<p>More information about this ticket</p>
<p>Title: $this->title$</p>
<p>Description:
<pre>
$this->description$
</pre>
</p>
<p>Public log:</p>
$this->html(public_log)$
<hr>
<p>Click here to display the details of the ticket: $this->hyperlink()$ (authentication required)</p>
</body>
</html>

Extended syntax

The extended syntax provides a quick means to retrieve data from related objects, by following any of the external keys of the triggering object like in the following examples:

$this->approver_id->phone$
$this->approver_id->org_id->code$
$this->approver_id->org_id->hyperlink()$
$this->parent_request_id->hyperlink(portal)$

Every built-in functions and attribute representations are available (but only after the last ->).

Testing notifications

To test a new action, you can use the status “Being tested” and fill “Test recipient” with a test address. In that case, the notification will be sent to this latter address. Once the notification have been tested, change its status to “In Production” to have notifications flow to their actual recipients.

If you want to de-activate an action, just set its status to “Inactive”.

Creating a trigger

When a new object is created
When an object enters in a given state
When an object leaves a given state
When an object is updated from the iTop portal
When the given threshold for a Time-To-Resolve (TTR) or a Time-To-Own (TTO) is reached

To create a new trigger, click on “New” in action drop down list for the given category in “Trigger” tab. The following wizard appears:

You have to select which type of trigger you want to create:

Trigger (on entering a state)
Trigger (on leaving a state)
Trigger (on object creation)
Trigger (on threshold)
Trigger (when updated from the portal)

Once you have selected the type of trigger you get the following form:

Any type of trigger requires you to specify three parameters:

Description is left to you to further identify the purpose of this trigger.
Class defines the class of object for which this trigger is applicable.
Filter restrict the objects to which the trigger applies. It is an OQL query returning all the objects that would activate the trigger. Leaving it blank means: all the objects of the expected class.

Depending on the type of trigger, you will have to define additionnal parameters:

On entering/leaving a state both require the state. The value to be entered for the “state” is the internal code of the state, as defined in the data model. State codes can be seen in the “Life Cycle” tab of the “Data Model”, section “Transitions”. The value code is the value listed between parentheses.
On threshold requires a stop watch and a threshold. The expected value for the stop watch is an attribute code. User Requests and Incident tickets come with two stop watches: tto and ttr. The threshold is a percentage of the goal of the stop watch. With the standard data model you can use 75 or 100.

The “Triggered Actions” tab defines which action(s) will be executed when this trigger fires. Remember that one action can be linked to several triggers, so it's possible to reuse some actions. The “Order” field determines in which order, for a given trigger, the actions are executed (actions are launched in ascending order).

We strongly encourage you to test triggers and actions before moving them to production, by using the “Being Tested” status on actions.

You can use the menu “Application log” where all notifications are tracked to check if an email was triggered. A detailed log of event describes what happened with a given notification, for an easier troubleshooting.

You can as well see which notification had been sent for a given ticket (User Request, Incident, Change) using the tab “Notifications” in the details of the ticket.

You can also list all sent and failed notifications by using the page “Admin tools” / “Run Queries” and running the query:

SELECT EventNotification

If you are running iTop on a Linux server, make sure that the variable “sendmail_path” value in php.ini. For example:

sendmail_path = "/usr/sbin/sendmail -t -i"

Depending on your actual environment, the configuration may be different. For example it is also possible to use SSMTP as a proxy to the actual email server, as explained in the following link: http://tombuntu.com/index.php/2008/10/21/sending-email-from-your-system-with-ssmtp/

If you are running iTop on a Windows server, you need to make sure that the php.ini file contains the following lines:

SMTP = <smtp server>
smtp_port = 25

In order to test email notifications you can use, the “Test Page” (follow the link from the “Notifications” pages) or type:

http://<itop server location>/setup/email.test.php

The test page performs a number of checks on the PHP configuration and allows you to send a plain-text email to the recipient of your choice. This is useful for validating that the PHP configuration of the server is indeed correct for sending emails.

Email Configuration

iTop 2.0 supports two methods for sending emails: the built-in mail function of PHP or SMTP via the Swift Mailer library (installed with iTop). The configuration parameter email_transport determines which method is used for sending eMails from iTop. If the value of the email_transport parameter is PHPMail (which is the default value), then the built-in mail() function is used. If the value is SMTP then the SMTP transport of Swift Mailer is used.

When using PHP's mail function the language's settings are used. Check the PHP documentation for more information.

When using the SMTP transport, the following parameters can be set in the iTop configuration file:

Configuration parameter	Type	Visible	Description	Default Value
email_transport_smtp.encryption	string	No	tls or ssl (optional)
email_transport_smtp.host	string	No	host name or IP address (optional)	localhost
email_transport_smtp.password	string	No	Authentication password (optional)
email_transport_smtp.port	integer	No	port number (optional)	25
email_transport_smtp.username	string	No	Authentication user (optional)

Though it seems easier to use the default transport (PHP mail), the drawback is the lack of reporting when it fails. For instance, you may get the error message “No valid recipient for this message.” for a configuration issue. More information in Swift Mailer transports documentation. Therefore, we strongly encourage you to use the SMTP transport, which will return detailed error messages.

Notifications and application responsiveness

Sending emails is a relatively slow operation. Depending on your email server, sending one email may take several seconds (establishing the connexion to the server, sending the data, etc…). When a Ticket is created or updated in iTop, several emails may be emitted, depending on the notifications configured. This can take a few seconds to complete. To improve the responsiveness of the application, the notifications can be sent asynchronously by a process running in the background on the web server. To activate the asynchronous sending of notifications, set 'email_asynchronous' ⇒ true, in the configuration file and make sure that the background process is up and running.

If you rely a lot on notifications, note that a direct SMTP connection using the SMTP transport is generally a bit faster than PHP's built-in mail function (PHPMail), so it may be worth the extra configuration effort.

Sidebar