Global requests management

Combodo's customers only

name:
Global requests management
description:
Group multiple service sub-categories within new global tickets
version:
1.3.0
release:
2022-02-09
itop-version-min:
2.7.0
code:
itop-global-requests-mgmt
diffusion:
ITSM Designer

Features

Some situations, like the arrival of a new employee or the departure of a sub-contractor, requires multiple actions to be performed by multiple teams. With a manual process, there is some drawbacks, such as:

  • An action can be forgotten to be requested,
  • An action can be required while prerequisite aren't performed yet.
  • Requiring the different actions independently force to reenter the same information multiple times.

This extension address the drawbacks listed above, by automating the creation of the multiple requests.

User experience: On the iTop User Portal,

  • The requester chooses in a catalogue of Global Demands, the one corresponding to his need, for example “Arrival of a new employee”,
  • Then he is prompted from global information related to this situation, in our case “employee name” and “arrival date”
  • All the actions required in this situation are listed, in our case it could be “Ordering a new PC”, “Ordering a company access badge”, “Ordering a mobile phone”,…
  • The requester can uncheck some of the proposed actions.
  • Then a single page prompt for all additional parameters needed for performing the selected actions.
  • When the requester submit his Global Demand, it automatically creates as many User Requests as there are actions requested in the Global Demand.
  • Then the requester can follow each User Request, as if he had created them separately.
  • His Global Demand will be automatically closed when all its User Request will be.

In details:

  • Groups several service subcategories under a new type of ticket called Global User Request,
  • At creation of the global request, automatically creates the different user requests associated to the service subcategories attached to the global user request,
  • Handles all the user requests templates at once, if any,
  • Provides a 2 level approval scheme for the global requests, and the user requests
  • Set the individual user requests on hold until the global request is approved,
  • Prioritize the processing of the user requests,
  • Automatically close the global demand when all user requests are closed,
  • Applied SLAs are specific to each User Request, depending on the associated Service. This is the major difference brought by this extension, if compared to Catalog of Procedure
  • Definition of global request types is managed trough a specific typology element,
  • There are no limitation in the number of global request types that can be created,
  • A given type of request belongs to one of the 3 following codes: arrival of an employee, departure of an employee, generic case, each of them defining a set of specific attributes for the global request,
  • Different global request types with the same code may be created, linked to a different set of service subcategories.

Revision History

Date Version Description
2022-02-09 1.3.0 * Compatibility with iTop 3.0.0 (new UI components)
* Change the minimum version of iTop to 2.7
* Remove all deprecated function from iTop Extensions
2021-12-15 1.2.1 * Compatibility with iTop 2.7.6 and 3.0.0 (datatables.net library update)
* Compatibility with iTop 2.7.6 (enable_formmanager_content_check module parameter)
2020-06-15 1.2.0 * Fix status not correctly updated in children UR
2020-10-09 1.1.2 * Mask attachement links because they are not managed
2020-03-18 1.1.1 * Fix service subcategories link being present in creation form
2020-03-11 1.1.0 * Add compatibility with iTop 2.7.0
* Add tab counter on global requests Manage brick
* Enable navigation rules for global request forms (iTop 2.7+ only)
2019-10-23 1.0.1 * Fix unitary_request_rules : cannot use an implementation class and prevents multiple action rule executions
2019-09-17 1.0.0 * Deny adding Incident ServiceSubcategory in GRType
* Portal form improvements
* Fix manager in GlobalRequestArrival portal edit form
* Add manager in GlobalRequestDeparture and Generic portal edit form
* Add GlobalRequest* classes in the approval brick
* GlobalRequest rejection cancels UserRequests
* Disallow to reopen rejected GlobalRequest
* UserRequest copy flags on waiting_for_gr_approval from waiting_for_approval
* ServiceSubcategory.parent_servicesubcategory_id new filters (request type, id)
* New GRType tab in ApprovalRule console form
* Remove “impact analysis” tab in GlobalRequest classes
* Modify waiting for approval menu to use approval-base report.php
2019-03-28 0.2.3 - Fix filtering of subcategories in a GlobalRequest regarding its GRType
- Fix default sort order for GlobalRequest objects
2019-03-27 0.2.2 - Fix “Add subcategories” button on non standard portals
2019-03-22 0.2.1 - Portal: Fix non scrolling modals
- Portal: Fix crash on GR Arrival creation
2019-03-05 0.2.0 - Unitary requests form now customizable in the brick definition
- Add option to set action rules on the unitary requests being created
- Add option to preselect all service sub-categories when creating a global request
- Add possiblity to add service sub-categories to an existing global request
2018-06-07 0.1.0 First release

Limitations

  • Requires Approval Process Automation, Customized request forms and Dispatch User Request to a team,
  • As a result, it is not compatible with the iTop Essential product.
  • Global Request can only be created in a Portal, not in the console.
  • A given service subcategory can only be linked to one direct parent subcategory of higher priority. When a subcategory has a parent, if it is selected, its parent subcategory is automatically included, even if not part of the “Global Demand Type”, assuming it is visible by the user.
  • During Global Request creation, you can't add an attachment to a Global Request nor to any depending User Request. You can do it later, by updating the User Request.

Requirements

Requires at least iTop 2.4.0.

Installation

Use the Standard installation process for this extension.

Since 1.2.0, this extension overwrites Ticket::DBUpdate() method. If one of your customization overwrites this method too, be sure to include also the below code and that every child Ticket class which overloads that method as well, does call its parent
Ticket::
public function DBUpdate()
{
        $this->WaitForPriorityRequest();
        if (count($this->ListChanges()) > 0 ) {
              parent::DBUpdate();
        }
        $this->ProceedPendingPriority();
}

Configuration

After installing this extension, configure a proper email_sender and configure trigger/action to ensure “Approval eMails” delivery of Global Demand.

The following settings are available to configure the module:

Parameter Type Description Default Value
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
target_state string State that may trigger the approval process. The transition wait_for_approval has to be defined for this state. Default “new”.
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
reuse_previous_answers boolean If a person is approver at both level then his level 1 decision is reused at level 2 true

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

  • email_asynchronous
  • email_transport

In the end-user portal, creation of a global request is possible through the GlobalRequestBrick. One instance of the brick is added to the standard portal by default with the ID new-global-request. The brick is based on the CreateBrick so it has the same parameters (see here) plus some specific ones:

Search in the XML:
Tag Usage Description
<brick id="UNIQUE_ID" xsi:type="Combodo\iTop\Portal\Brick\GlobalRequestBrick"> zero or more Create a global request and its sub-requests.
<subitems_att>parent_servicesubcateogry_id</subitems_att> optional Attribute code in the subitem class (usually ServiceSubcategory) to get the parent subitem. This is used to compute dependency between subitems.
<available_subitems_oql>SELECT ServiceSubcategory AS SSC JOIN lnkGRTypeToServiceSubcategory AS l1 ON l1.servicesubcategory_id = SSC.id JOIN GRType AS GRT ON l1.grtype_id = GRT.id JOIN Service AS S ON SSC.service_id = S.id WHERE GRT.id = :grtype_id</available_subitems_oql> optional OQL that filters available subitems (usually ServiceSubcategory) to choose from to create sub-requests. Note that the :grtype_id placeholder will automatically be replaced with the id of the GRType class been created.
<preselect_all_subitems>true</preselect_all_subitems> optional Define if subitems should be preselected when creating a global request. Available values are true|false, default is true.
<unitary_request_form> optional Prompted information for the unitary requests. Note: Only the twig tag of the usual form syntax is suported for now.
<unitary_request_rules> optional Action rules that should be applied on the unitary requests when creating the global request.

Usage

Global Request Types

As a prerequisite, iTop administrator needs to define the types of Global Requests that portal users can create. For that purpose, he'll need to create new Global Request Types from the Typology configuration menu available under Data administration.

 Define Global Request Type

Name Type Mandatory Description
Name Alphanumeric string Yes A name describing the GR Type
Code Enum: Arrival, Departure, Generic Yes Class of global request
Approval rule Foreign key to a(n) Approval Rule No Approval rule to use for this type of GR
Service subcategories N:N links No* All the service subcategories that are grouped under that type of GR

(*) Technically Service Subcategories are not mandatory, but a Global Demand Type without any is useless, as no Global Demand of this type can be ordered in the portal in that case.

  • Several global request type can rely on the same code. This can be useful if you want to make a difference between, for instance, the arrival of an employee and the arrival of a contractor.
  • Global requests with the same code have the same predefined attributes but may be linked to different sets of service subcategories.

Service subcategories

To improve the efficiency of Global Demand, some service subcategories need to be performed before others, as they are dependent. This dependency can now be specified thanks to a parenthood attribute.

 Global Request Management parent service subcategory

The different user requests created under the same global request, use this service subcategory hierarchy for processing parent first, and starting the children only when the parent is resolved. Example if, for instance, the “New DNS name” subcategory has the “New IP Address” as a parent, then, the user request for the “new IP address” will need to be resolved before the user request for the “new DNS name” can be processed.

The Parent Service Subcategory attribute can of course be left empty.

If a service subcategory depends from another its parent is automatically added to the Global Demand even if not part of the Global Demand Type, and it cannot be unselected

A service subcategory can be used for different Global Request Types.

User Requests

This class of tickets is, as well, modified by the Global Request extension.

 Global request management new fields in User requests

A few attributes are modified or added…:

Name Type Mandatory Description
Status Enum: Waiting for Global Request approval, Pending priority request (GR), Cancelled Yes
Parent Global Request Foreign key to a(n) Global Request No Set if ticket has been created from a Global Request
Request processed first Foreign key to a(n) User Request No User Request that needs to be resolved first
The operational_status of the class Ticket has been enhanced with the new value 'waiting_for_approval' that groups the tickets with the same status.

… and the life cycle has been adjusted accordingly:

The 3 new status have been inserted at the beginning of the standard life cycle of a User Request.

  • Waiting for Global Request approval: Pending the approval of its parent Global Request,
  • Pending priority request (GR): Pending the resolution of a UR with higher priority,
  • Cancelled … if the Global Request has not been approved.

Dedicated Approval Process

A specific approval process has been created for the Global Requests. Like the standard Extended Approval Scheme this one relies on the Base Approval module.

Please, refer to the Approval process automation documentation if required.

Creation of a Global Request

A Global Request can only be created from the portal. For that purpose, the extension brings 2 additional bricks to the standard portal:

  • One to handle the creation process
  • Another one to list and update the ongoing requests
No global request should be created from the console ! The engine that automatically creates the associated user requests is only implemented in the portal. Note that no mechanism in iTop prevents this to happen, though.

At creation time, the user is required to select a Global Request type among the ones available.

Once selected, he fills the different attributes related to the request and selects the service subcategories to be created and processed as part of this global demand.

  • All subcategories are selected by default.
  • If a selected service subcategory depends on a parent subcategory, then the parent cannot be removed from the list of of selected subcategories.

When the user submits the request, iTop will check first that no customized request form (request template) needs to be filled. If this is the case, then a page is displayed where the user can fill its choices.

Pressing the “Submit” button will create the global request and all associated (unitary) user requests.

The newly created global request will then follow its life cycle.

During the life cycle of a global request, the requester can update its public log in order to provide further information to the support agent in charge of the request. He may as well change the list of contacts and add an attachment. The global request is automatically closed when all individual requests are closed.

Once created, the individual user requests will follow their own life cycle. However, a user request linked to a parent user request of higher priority will wait in the status 'pending priority' that the parent ticket is resolved before following its own cycle (approval process, dispatch, assignment…).

Management of Global Requests

Global Requests are managed from the console where a dedicated menu group, including an overview, is added by the extension:

 Global request management dashboard

The search and open menus, below the Overview, handle global requests, regardless their final class…

 Global request management dashboard search

… where the Shortcuts menus look after each individual final class of global requests.

 Global request management dashboard

The “waiting for approval” menu lists all global requests that are pending for an approval. Should that be necessary, an administrator (or any profile that have the appropriate rights) may bypass the approval process for a request, from that menu, and that way, move the global request directly in the state “work in progress”.

Questions & Answers

Usage

Q: When should I use “Global request management” instead of “Catalog of procedures”?
A: Both offer to automatically create sub-objects with dependencies, based on a predefined template, but with “Global request management” you can:

  • pick and choose the sub-objects to create (by selecting the service-subcategories) during Global Request creation
  • define complex sub-objects, thanks to “Customized request forms”
  • track SLA on each sub-object
  • manage approval on the sub-object level

Q: How Global Request extension work if one of my “Global Request Type” Service/Service Subcategory is not link to my Customer Contract ?
A:

  1. If your Service Subcategory has no Parent service subcategory, this Service Subcategory won't be proposed in the Service subcategory of your Global Request. The regarding UserRequest won't be created.
  2. If your Service Subcategory has a Parent service subcategory which is linked to your Customer Contract, the regarding UserRequest will be created if you choose The Parent service subcategory.

Q: What happen if a manually suppress a User Request part of a Global Demand?
A: If another User Request within the Global Demand was waiting for the resolution of the delete one, then it will wait forever, and can only be deleted also.


Q: Who can create Global Request in the Portal?
A: Any Portal user can create a Global request in the Portal by default. This can be changed by customizing the Portal.


Q: Can I create a Global Request in the Console?
A: No. Also there are means to create a Global Request object in the console, it will not propose any service sub-categories and won't create any associated User requests, so it should not be done.


Q: Can I clone a Global Request in the Console with an object copier action?
A: No. For similar reasons as for the above question.


Q: Can I csv import Global Requests?
A: No. For similar reasons as for the above question.


Q: What happen if during the GRType creation, we put a circular reference in the service subcategory dependency?
A: Such situation is not checked. To prevent it, you can change the type of the field parent_servicesubcategory_id from ExternalKey into HierarchicalKey.


Troubleshooting

Q: Creation of Global Demand in the portal fails with error: “Twig content not allowed in this context!”
A: This is due to a security fix brought by iTop 2.7.6. In order to fix this just add this config parameter

Configuration file
$MyModuleSettings = array(
  'itop-portal' => array(
    'enable_formmanager_content_check' => false,
  )

Customization

Q: How can I choose/force Impact and/or Urgency for UserRequest automatically created by a Global Request?
A: UserRequest are created with default parameters for Impact and Urgency. If you want to force Impact and/or Urgency, you need to add two items in globalrequest-to-unitaryrequest <action_rules> in your Portal Design. These new values will be set for all UserRequests created by a Global Request.

itop-design / module_designs
<module_design id="itop-portal" _delta="must_exist">
      <action_rules>
        <action_rule id="globalrequest-to-unitaryrequest" _delta="redefine">
          <source_class>GlobalRequest</source_class>
          <presets>
            <preset id="1">set(origin, portal)</preset>
            <preset id="2">set(impact, 1)</preset>
            <preset id="3">set(urgency, 1)</preset>
          </presets>
        </action_rule>
      </action_rules>
</module_design>

Q: Can I propose a mean to my Portal users, to create Global Requests or User Request in a single menu?
A: With iTop 2.7, there is an option, with a BrowseBrick, displaying GRType and below Service sub-category. The top level would create a GlobalRequest, while the level below would create a simple UserRequest. Note that this cannot include Incident, will maybe propose the same service subcategory multiple times and will not propose service subcategories which would not be part of a GRType.


Q: Is there any dependency between the Global Request & associated UserRequest caselogs?
A: Out of the box, no. You may put some using standard customization in the ITSM Designer if you have PHP developer privilege.


Q: Can I use the CreationBrick for creating Global Request?
A: No, you have to use the Brick brought by the extension.

extensions/itop-global-requests-mgmt.txt · Last modified: 2022/04/07 10:59 (external edit)
Back to top
Contact us