Tips for administrator
Tips for administrator
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:
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:
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:
$this→agent_id→email$. Note that some email servers will reject the message if the “from” address is not valid.
Test recipientemail address
$this→team_id→email$. This a standard attribute of an email message. It is used automatically by mailing tools as the address to use, when the user does “reply” on the email in his mailer. If omitted the
fromaddress is used.
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 a single email attribute, namely:
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
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
The query can contain placeholders that refer to the current contact which has done the action at the origin of the event (might be an issue if the user is not linked to a contact). The syntax is
For example, to send a notification to the agent only if he did not triggered the event himself, the To field will contain:
SELECT Person WHERE id= :this->agent_id AND id != :current_contact_id
Since iTop 2.3 this syntax works also:
:current_contact->id which is equivalent to
and even in a more generic manner:
If the list returned by the query is empty no email will be sent.
SELECT Person JOIN lnkContactToTicket AS L ON L.contact_id = Person.id WHERE L.ticket_id = :this->id
SELECT Person AS P JOIN lnkContactToFunctionalCI AS L1 ON L1.contact_id = P.id JOIN FunctionalCI AS CI ON L1.functionalci_id = CI.id JOIN lnkFunctionalCIToTicket AS L2 ON L2.functionalci_id = CI.id WHERE L2.ticket_id = :this->id
Starting with iTop 2.3.0, the message body is now edited using a WYSIWYG HTML Editor.
The “Subject” and “Body” parts can be build dynamically by using placeholders. The syntax to be used for such placeholders is
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->attribute_external_key->attribute$refers to the field attribute of the object pointed by attribute_external_key it-self being a field 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:
Check here the details of those various types of placeholders
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”.
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:
More Trigger can be added by specific extensions such as:
Once you have selected the type of trigger you get the following form:
Any type of trigger requires you to specify three parameters:
Depending on the type of trigger, you will have to define additional parameters:
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).
Portalcan replace the trigger when updated from the portal and be more specific, by specifying a particular portal and/or particular modified fields
Triggers brought by old versions of extensions will not propose Contexts.
Consoleby design of the extension.
You can see which notification had been sent for a given ticket (User Request, Incident, Change) using the tab “Notifications” in the details of the ticket.
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/
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.
iTop 2.0 supports two methods for sending emails: the built-in
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
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)|
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.
SMTPtransport is generally a bit faster than PHP's built-in mail function (
PHPMail), so it may be worth the extra configuration effort.