iTop Extensions

Approval Extended

Approval Extended
Extended approval management module

This module provides the capability to handle a two levels approval process for a user request, with several approvers in parallel on each level.


  • Automated, rule based, approval mechanism
  • Two levels of approbation with several approvers in parallel at each level
  • Approvers can approve or reject a request in one click from an email (no need to have an iTop account)
  • Passive or active approval
  • Configurable timeout delay
  • Graphical view of the approval status on each ticket

Revision history

Date Version Description
2015-09-30 1.1.3 Disable the standard attributes UserRequest::approver_id and approver_email, as they do not make sense when this module is installed. Removed the “plus” button from the Approval Rule edition form, to workaround a bug in the coverage windows creation form (when shown as a dialog, requires a fix in the core of iTop, related to the component “SLA With Coverage Windows” version >=2.1.0, or the module “combodo-coverage-windows-computation>=2.0.0)
2014-12-18 1.1.2 Manually send a reminder ; Support of several executions on the same ticket (works retroactively with data recorded prior to this version) ; Record something into the log even if the comment is left empty (was already done when bypassing the process) ; If an approver already gave her answer the approve/reject menus must be hidden ; If a user bypasses the process, and if her account has a contact defined, then the identifier of the user (shown in the header of the new log entry) must be the contact friendly name (not the user login) ; Changed the misleading message “is now complete with failure” into “is now complete with result REJECTED” ; Prevent the CRON from creating one CMDBChange record per minute ; Fixed typos in the french dictionary ; Changed the module name (internal)
2014-04-24 1.0.3 Better error reporting when an email address is wrong or missing. In particular when the module has just been installed, the configuration entry sender_email is left empty and this produces a scary error message when the email transport is SMTP
2014-03-07 1.0.2 Integration of the German translation (thanks to ITOMIG GmbH)
2014-03-05 1.0.1 First release (fixes a bug found the prototype: always approve on timeout, whatever the setting in the approval rule)


Requires iTop 2.0.2 (because of the edit mode “add_remove” for a direct linkset).


  1. Download the package and expand the 3 folders “approval-base”, “combodo-approval-extended”, “combodo-sla-computation” into the “extensions” directory of iTop.
  2. If you have already installed iTop, make sure that the configuration file config-itop in conf/production is NOT read-only.
  3. Point your web browser to http(s)://<your_itop_root>/setup and follow the wizard instructions. Make sure that you select the option to “Upgrade an existing iTop instance”:
  4. Finally check the module “Extended approval scheme(on user requests)” in the list of extensions at the end of the interactive wizard. Then complete the installation.


After installing this module, first configure a proper email_sender to ensure a consistent eMail delivery.

The following settings are available to configure the module:

Module Parameter Type Description Default Value
approval-base email_sender string Sender eMail address, as seen in the approval email. If left blank, sending the email will likely fail.
approval-base email_reply_to string Default “reply to” eMail address for the approval email. (optional) defaults to email_sender
approval-base comment_attcode string Attribute into which the user comments will be reported. Can be a case log or text. The comments are all aggregated. Note: the comment can also be viewed as a tooltip. (optional)
approval-base list_last_first boolean In case several executions occur, drives the order in which the results of the executions are displayed (vertically). false
approval-base enable_reminder boolean Enable the feature “send a reminder”. true
approval-extended enable-admin-abort boolean Allow defined profiles to bypass the approval process. Profiles allowed to bypass the process are defined in the variable bypass_profiles. true
approval-extended target_state string state that may trigger the approval process default “new”. Warning: the transition wait_for_approval has to be defined for this state.
approval-extended bypass_profiles string CSV list of profiles. Having any of the given profiles is sufficient to be allowed to bypass approval processes. Set to an empty string to deny the feature to anybody. Administrator, Service Manager

The following standard settings might be of interest when setting up the approval feature:

  • email_asynchronous
  • email_transport



When a User Request is entering the state new, the approval engine verifies if there is an approval rule defined for the corresponding service subcategory. If yes, then the state of the user request is set to wait for approval and a notification is sent to the approvers defined in the approval rule. Only the approvers corresponding to the first level are notified. Once the request is approved, and if a second level has been defined, then the second level approvers are notified. Should the approval be rejected (by an approver, or on timeout), then the process finishes in any case.

The email contains a web link to display the web page to approve or reject the request. The approver does not need to login into iTop (the links contains that information).

The approvers will have a delay defined in the approval rule to give their answers. This delay takes into account the coverage window defined in the approval rule.

Once the approval delay has expired, the approval process terminates. The result (approved or rejected) is then taken in the property Automatically approved if no answer at Level 1/2 of the approval rule.

The User Request will then continue its way through its lifecycle, depending on the approval status: rejected or approved.

Create approval rules

From the Service Management menu, click on Approval rules:

The pages show a list of already defined approval rules. Click on the button “new” to create a new one:

An approval rule is identifier by it name. The coverage window is used to compute the approval delay.

The fields “Approval level1” and “Approval level2” define, via an OQL query, the list of approvers for each approval level. These queries must return elements having an email attribute (e.g. Person or Team). It is possible to use the place holders :this→attribute that make reference to the attributes of the user request.

For instance :this→caller_id for the caller, :this→service_id for the service … All attributes defined in the data model for a service request can be used.

The field “Automatically approved if no answer ” determines if the request will be approved or rejected if there is no answer after the defined delay.

The field “approval delay (hours)” defines the delay in hours for each level of approval.

Once the approval rule has been defined, you can assign it to a service subcategory, either from the approval rule itself (tab Service subcategory) or from the service subcategory:

My ongoing approvals

From the Helpdesk menu, click on Ongoing approvals:

The page shows a list of the User Requests having an approval process running, and for which your approval is being requested:

Approve or reject

From the user request, open the Other actions menu and select Approve or Reject:

The approval form is displayed:

After the reply has been given, you are redirected to the user request and a banner reminds you the outcome of your reply.

Bypass the approval process

If you are an administrator, and if the setup allows it, then you have a menu to bypass the process:

The approval form is then a little different than the standard reply form: it reminds you that bypassing the process is a little different.

If you are both an approver and allowed to bypass the process, then both menus are allowed. Using one or the other will just change the way the approval process result gets recorded and further displayed in the status tab.


As soon as a user request has been through an approval process, the tab Approval status shows detailed information about the ongoing or terminated approval.

Ongoing approval

In the above example, the deadline is displayed in bold: 21st of january at 12:47.

Click on the button “send a reminder” to send a new message to the approver (confirmation required). This feature can be disabled by setting the parameter enable_reminder to false.

After the reply has been given, the status appears in clear:

Rejected approval

Move your mouse over the image next to the approver's name, and you will get the date of the answer and her comment if any has been given:

The status will be entirely reset anytime the user request enters the state “waiting for approval”.
extensions/approval_extended_1_1.txt · Last modified: 2018/12/19 11:40 (external edit)
Back to top
Contact us