User Tools

Site Tools

:: Version 2.2.0 ::

2_2_0:products:professional:admin_approbation
Translations of this page:

Overview

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.

Please see how it will be perceived from the end user perspective in the user guide.

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:

Monitoring ongoing approvals

In addition to the tab showing the status of a single approval (ticket view), a view shows all the ongoing approval processes.

It is accessible from the Helpdesk menu:

The page shows a list of the User Requests having an approval process running, independently from the ticket state.

Uncheck “show items for which my approval is requested” and you will see each and every ongoing approval.

Click on the User Request reference to open the ticket then select the tab Approval status to get detailed information about the ongoing approval.

A User Request will exit the list when the approval process is over.

Settings

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. None: the comment can only be viewed as a tooltip (optional)
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_profilestrue
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

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

  • email_asynchronous
  • email_transport
2_2_0/products/professional/admin_approbation.txt · Last modified: 2018/12/19 11:40 (external edit)

";