:: Version 3.3.0 ::

iTop Essential 3.1 to 3.2 Migration Notes

This version of iTop is backward compatible with previous versions,
However read carefully the topics described in this page to ensure a smooth migration of your iTop.

Impact on Users

Before migration

Better not upgrade without Combodo or its partner.
  • We have an audit tool to prevent bad surprises
  • Most of the checks listed below can be smoothly and quickly checked on your particular ITSM Designer license by Combodo
  • A few compatible extension versions must be activated and moved to production before upgrading your iTop

System

PHP version

PHP extensions

MySQL / Maria DB version

Database

Database update operations

Extension / Custom code

As usual some extensions must be upgraded at the same time as your iTop, or after for ???4?? of them.

The DisplayBareProperties method id in DocumentFile changed from DisplayBareRelations to DisplayBareProperties to be more consistent with the defined function. If you have redefined this method, you will need to change the identifier.

If you have developed custom extensions with XML and custom code, check: Developer check-list

Extensions to upgrade

Check for each of your Combodo extensions the 3.3 compatible version that you need to install, before upgrading.

Backoffice themes

Using an undeclared SCSS variable as the value for another variable is deprecated. To ensure compliance with Sass specifications, please use static values (e.g., Hex codes) or variables that you defined beforehand.

Portal themes

As the User Portal New Look is now the only User Portal, all previous extensions customizing the portal theme are no more working.
A new extension must be written following the new standard: question_answers

Included in iTop

XML Datamodel

After many years of Datamodel stability, this version brings multiple improvements to the default iTop Datamodel.
As a result your own customization by extensions or Designer may generate XML conflicts with the new version

The way to resolve those conflicts impose to modify your extensions and/or modify your model in the Designer.
There are different use cases:

  • Node xxx/xxx/xxx already exists so cannot be created
    • Your customization have exactly anticipated the evolution brought by iTop 3.3 Datamodel ⇒ Remove your customization
    • Your customization is different also the node id is the same ⇒ replace the _delta=“define” by a _delta=“define_if_not_exists
  • Node yyy/yyy/yyy not found so cannot be modified/removed
    • if it wanted a removal ⇒ Remove your customization
    • if you wanted a modification ⇒ Check your modification to see if you can just replace the “redefine” by a “define” or if it requires to provide a wider XML branch to be effective.

CMDB

This version adds fields to CMDB classes

  • If you have redefined the presentation details of those classes by extension or with the Designer, those enhancements won't be visible in your iTop.
  • If you have done any type of XML customization it can conflict with the 3.3.0 Datamodel changes. First conflict found is reported during iTop Setup, XML compilation phase. The error message identifies the module and node in conflict.
    • For the community, check the exhaustive list in the link above and adapt your XML extension(s)
    • For Combodo's customers, ask for the Migration Audit report, which will identify the conflicts with your customization if any.

Service Management

Status Mandatory

  • Service and Service Subcategory status are now mandatory.
    • Any such object with an undefined value will become implementation after upgrade
    • Those undefined were not visible in User Portal while implementation were visible (before upgrade)
    • After upgrade, unless you have modified those classes scopes in the User Portal implementation are no more visible in the User Portal except for Users with the Service Manager profile, so they can test new Service Subcategory (especially pertinent with Customized request forms).

New Menu groups

If you have reorganized those menus, the new dashboard menu may appears without all its expected sub-menus

Ticketing

  • New field parent_request_id on class Incident

Copy parent log

  • New prefix on log entries copied from parent Ticket + code refactoring:
    • new method on class Ticket UpdateChildTicketLog adding a prefix to the log entry copied from the parent Ticket and being more efficient
    • Modification of methods UpdateChildRequestLog and UpdateChildIncidentLog on classes UserRequest and Incident, to call Ticket::UpdateChildTicketLog
  • The method can be reuse for any log
  • Parent log and child log can be different, you can copy the public parent entry within the private child log if you want.
  • The prefix is associated with the parent Ticket log, so it describes the source. A parent User Request public log entry, will always have the same prefix regardless where it is copied.
  'Class:UserRequest/Method:UpdateChildTicketWith:public_log' => '<i><u>Public log automatic copy from parent User Request %2$s:</u></i><br><br>',
        'Class:UserRequest/Method:UpdateChildTicketWith:private_log' => '<i>Private log automatic copy from parent User Request [[UserRequest:%1$s]]:</i><br><br>',
        'Class:Incident/Method:UpdateChildTicketWith:public_log' => '<i><u>Public log entry from parent Incident %2$s:</u></i><br><br>',
        'Class:Incident/Method:UpdateChildTicketWith:private_log' => '<i>Private log entry from parent Incident [[Incident:%1$s]]:</i><br><br>',

Setup

Configuration file

After Migration

On the ITSM Designer

After you have upgraded your iTop staging instance and connected it to the ITSM Designer, you may want to benefit from available new features

Trigger on Attachment

If you have configured a Trigger (on object creation) or a Trigger (on object deletion) on class Attachment, those triggers can no more be modified

You should replace it with the new classes of trigger brought by version 3.3.0:

3_3_0/products/essential/release/migration.txt · Last modified: 2026/07/23 16:11 by 127.0.0.1
Back to top
Contact us