Global requests management
Combodo's customers only
- name:
- Global requests management
- description:
- Group multiple service sub-categories within new global tickets
- version:
- 1.5.0
- release:
- 2024-09-12
- itop-version-min:
- 3.2.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 |
---|---|---|
2024-09-12 | 1.5.0 | * N°7151 - Raise iTop min. version to iTop
3.2.0 * N°7151 - Add compatibility with iTop 3.2+ (and migrate for Symfony 6.4) * N°7558 - PHP 8.0: Fix crash when creating Global Request without beneficiary_id * N°7656 - Fix error when adding a contact to an existing global demand * N°7656 bis - Allow sub-demand on a service not in user scope |
2023-12-13 | 1.4.1 | * N°6705 - Remove impact analysis tab * N°7041 - Fix global demand created without any of its child requests * N°7049 - Fix Unitary request created with origin “phone” instead of “portal” |
2023-07-17 | 1.4.0 | * Add compatibility with iTop 3.1 (Symfony
5.4) * Fix french dictionary entries for ServiceSubcategory friendlyname and service_id_friendlyname wrongly overloaded in the extension * N°2736 - Fix cancelled tickets not consider as closed (thanks to @Hipska!) * N°5607 - Fix module name for initialization of “reuse_previous_answers” and “bypass_profiles” parameters * N°5548 - The coverage window is now used to calculate the approval end time * N°6214 - Fix hard-coded class name in unitary request action rules processing (thanks to @Hipska!) * N°6075 - Add german translations (thanks to ITOMIG GmbH!) * N°6030 - Add label, friendlyname, uniqueness rules on Link classes |
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.
Avoid adding such CheckToWrite on UserRequest under a Global one
Requirements
Requires at least iTop 2.4.0.
Installation
Use the Standard installation process for this extension.
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
parentConfiguration
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:
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.
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.
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.
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.
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 |
… 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
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:
The search and open menus, below the Overview, handle global requests, regardless their final class…
… where the Shortcuts menus look after each individual final class of global requests.
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:
-
If your
Service Subcategory
has noParent service subcategory
, thisService Subcategory
won't be proposed in theService subcategory
of yourGlobal Request
. The regardingUserRequest
won't be created. -
If your
Service Subcategory
has aParent service subcategory
which is linked to yourCustomer Contract
, the regardingUserRequest
will be created if you choose TheParent 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, )
In 2.7.7, this bug is fixed, and this param is removed
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.