Combodo's customers only
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:
This extension address the drawbacks listed above, by automating the creation of the multiple requests.
User experience: On the iTop User Portal,
|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
Requires at least iTop 2.4.0.
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 parent
trigger/actionto ensure “Approval eMails” delivery of Global Demand.
The following settings are available to configure the module:
|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 ||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:
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:
|<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.|
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||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.
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.
This class of tickets is, as well, modified by the Global Request extension.
A few attributes are modified or added…:
|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.
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.
A Global Request can only be created from the portal. For that purpose, the extension brings 2 additional bricks to the standard portal:
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.
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…).
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”.
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:
Q: How Global Request extension work if one of my “Global Request Type” Service/Service Subcategory is not link to my Customer Contract ?
Service Subcategoryhas no
Parent service subcategory, this
Service Subcategorywon't be proposed in the
Service subcategoryof your
Global Request. The regarding
UserRequestwon't be created.
Service Subcategoryhas a
Parent service subcategorywhich is linked to your
Customer Contract, the regarding
UserRequestwill 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
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
Q: How can I choose/force Impact and/or Urgency for UserRequest automatically created by a Global Request?
UserRequest are created with default parameters for
Urgency. If you want to force
Urgency, you need to add two items in
<action_rules> in your Portal Design. These new values will be set for all
UserRequests created by a
<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
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.