iTop Professional 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.

For a focus on new features check What's new in iTop Professional 3.2
For an exhaustive list of changes check the Change Log

Impact on Users

Before migration

Better not upgrade without Combodo or its partner.

We have an audit tool to prevent bad surprises
Most Datamodel changes 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

New PHP min version: 8.1.0
New PHP max version: 8.3.x

PHP extensions

PHP extension APCu is now strongly recommended, otherwise performances could be slightly degraded.

MySQL / Maria DB version

MariaDB min version remains the same: 10.3.7
MySQL min version remains the same: 5.7

Database

Database update operations

N°6619 - Attachment : Make contact_id an AttributeExternalKey instead of AttributeExternalField

ALTER TABLE `attachment` ADD `contact_id` INT(11) DEFAULT 0
ALTER TABLE `attachment` ADD INDEX `contact_id` (`contact_id`)

Since MySQL 5.6 and MariaDB 10.3.7 this operation should be quick, unless you overwrote “ALGORITHM” config parameter.

Custom code / extension

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.2 compatible version that you need to install, before upgrading.

Portal themes

If you created a custom theme for the end-user portal that replaces bootstrap-theme-combodo.scss, you'll need to re-generate it. Otherwise some elements might not display correctly (HTML editor)

Included in iTop

XML Datamodel

The field “Solution” of classes User Request and Incident, now supports HTML.
To revert this datamodel change, add this XML into an extension or ask Combodo to inject it in the Designer for you

    <class id="UserRequest" _delta="if_exists">
      <fields>
        <field id="solution" xsi:type="AttributeText" _delta="if_exists">
          <format  _delta="delete_if_exists"/>
        </field>
      </fields>  
    </class>
        <class id="Incident" _delta="if_exists">
      <fields>
        <field id="solution" xsi:type="AttributeText" _delta="if_exists">
          <format  _delta="delete_if_exists"/>
        </field>
      </fields>  
    </class>

Setup

Configuration file

After Migration

Rename your Triggers

Because of the new unsubscribe mecanism, Trigger “Description” field will be visible to console users as the identifier of a notification that they have received, so that description should explain them, when this trigger is generated (also the might guess based on the trigger type, an explicit text might be easier to catch) and who receives them.

It might be useful to duplicate some of your Triggers and Actions, to separate notification to the ticket agent (1) and notification to people of their team or people linked to the ticket (2)
Thus a user can keep the first trigger and unsubscribe to the second. Otherwise, it's all or nothing…

Connect News

iTop 3.2.0 comes with 3 new actions “Notification by Newsroom”

One Notification to persons mentioned in logs automatically linked to all your existing “Trigger (on object mention)” searching for “Person” in the filed “Mentioned filter”

One Notification to agent when ticket assigned to be linked with a “Trigger (on entering a state)” on class “User Request” on “state:” assigned

One Notification on public log update through the portal to be linked with a “Trigger (when updated from the portal)” and a “Trigger (when updated by mail)” both on class “User Request”

All your “Trigger (on object mention)” triggers have their “Subscription policy” field (field added in 3.2.0), set to the value Force at least one channel (News or Email), because by default we don't want iTop Users to unsubscribe from all channels when their name is mentioned somewhere in an object log.

X-Content-Type-Options HTTP header and CORB protection

Since iTop 2.7.10 / 3.0.4 / 3.1.2 / 3.2.0, the X-Content-Type-Options HTTP header is sent with the nosniff value. This could trigger CORB protection for certain resources, preventing them from loading (see https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#determining-whether-a-response-is-corb_protected).

To mitigate the issue, sending this HTTP header is disabled on corresponding resources in iTop core.
As some extensions can be impacted, the security.enable_header_xcontent_type_options config parameter can be set to false to prevent the header to be sent.

Sidebar