The version 2.4.0 of iTop is fully backward compatible with the previous 2.x versions (2.3.4, 2.3.3, …, 2.2.1, 2.2.0, 2.1.0, 2.0.3, 2.0.2…), however this version introduces quite a few significative changes.

This document highlights issues which can occur while migrating your iTop to this version.

• For a focus on new features check What's New in 2.4
• For an exhaustive list of changes check the Change Log

A new capability has been added to iTop core to improve search performance when your outdated data start to represent much more than the active ones.

It is not enabled by default on iTop. It has to be activated by a module.

More on Archiving

Many objects will disappear from user screen and it may confuse them. If you want to minimize users' question on this, you can set your iTop to have a different default by adding a line in the Configuration file

   'show_obsolete_data' => true,

More on obsolescence

If the DisplayBareRelations method is overriden to display tabs containing lists with counts, the counts will not be correct if the user does not display the obsolete data. In order to display a correct count, the DBObjectSet used for the count should be aware of the user choice on obsolescence display. To do so insert the following code snippet:

For example :

$oSet = new CMDBObjectSet(DBObjectSearch::FromOQL($sOQL));
//
// Add the obsolescence filter here
   $oSet->SetShowObsoleteData(utils::ShowObsoleteData());
// End of patch
//
$iCount = $oSet->count();
if ($iCount > 0)
{
    $oPage->SetCurrentTab($sClassName." ($iCount)");
}
else
{
    $oPage->SetCurrentTab($sClassName); 
}     
self::DisplaySet($oPage, $oSet);

Standard Data Model of iTop 2.4 is using the new capability to define flags on transitions. Changes were made on class UserRequest (and Incident)

• on a re-assign transition from assigned to assigned state, agent_id is required to be changed.
• on an assigned state, the agent_id is read only.

As part of the default Portal, the re-open transition now prompts the user to provide information in the Caselog. It's optional, as the user may have provided it already in the Ticket form before re-opening.

zip library for php is limited to 4Gb backup size.
As a result, if your iTop database backup file exceed 4Gb, you will never be able to restore your data as the generated backup file is unreadable. So to address this known issue, we have decided to switch to tar.gz format which has no size limitation. This means that you will have to install phar and zlib on your iTop server.

It seems to be part of php package on Windows and of php7 on Ubuntu 0.16.04. It can be a library to add or may require a new php version.

Your existing backup files smaller than 4Gb and using zip format, can still be restored by iTop. But new backup file will be generated with tar.gz by defaut.

Legacy portal is now deprecated and will be removed as of iTop 2.7.0.

Some extensions providing new bricks or extending native bricks have been merged into iTop and are now obsolete. Using them in iTop 2.4 and above could result in a conflit. Here are the concerned extensions:

• itop-portal-create-brick-extended
• itop-portal-filter-brick

A new verb on DBObject is available. GetDefaultValue($sAttCode) is overridable and allows to change the default value of an attribute for an object. (One of its use case could be to set default values when creating a new object)

DBObject::Get on an attribute of type “link set” now returns an object of the class ormLinkSet whereas it used to return an object of class DBObjectSet.

DBObject::Set accepts either an object of class ormLinkSet (preferred!) or DBObjectSet (deprecated, but kept for backward compatibility).

Here is the supported (though deprecated) pattern:

$oCurrentSet = $oObject->Get('person_list');
$oNewSet = DBObjectSet::FromScratch('lnkSomeClassToPerson');
// Copy the current set
while ($oSomeLink = $oCurrentSet->Fetch())
{
        $oNewLink = MetaModel::NewObject('lnkSomeClassToPerson');
        $oNewLink->Set('name', $oSomeLink->Get('name'));
        $oNewLink->Set('firstname', $oSomeLink->Get('firstname'));
        $oNewSet->AddObject($oNewLink);
 
}
// Add an item
$oNewLink = MetaModel::NewObject('lnkSomeClassToPerson');
$oNewLink->Set('name', 'Doe');
$oNewLink->Set('firstname', 'John');
$oNewSet->AddObject($oNewLink);
$oObject->Set('person_list', $oNewSet);

Here is the recommended (simpler and more efficient) pattern:

$oCurrentSet = $oObject->Get('person_list');
$oNewLink = MetaModel::NewObject('lnkSomeClassToPerson');
$oNewLink->Set('name', 'Doe');
$oNewLink->Set('firstname', 'John');
$oCurrentSet->AddItem($oNewLink);
$oObject->Set('person_list', $oNewSet);

In iTop 2.4.x, UILinksWidget::Display and UILinksWidgetDirect::Display methods have not been updated according to the new ormLinkSet object, it only accepts DBObjectSet as $oValue parameter.

This means that you can use a ormLinkSet object (eg. from a DBObject::Get on a link set attribute like said on the previous point) directly, you have a convert it to the legacy DBObjectSet format. To do so, just use the ormLinkSet::ToDBObjectSet method.

Here is an example of a non working code:

// Prepare links widget
$oWidget = new UILinksWidget(...);
 
// Retrieve links
$oSet = $oObject->Get('person_list');
 
// Display widget
$oWidget->Display(..., $oSet, ...);

Here is the correction for the example above:

// Prepare links widget
$oWidget = new UILinksWidget(...);
 
// Retrieve links
$oSet = $oObject->Get('person_list');
$oLegacySet = $oSet->ToDBObjectSet(utils::ShowObsoleteData());
 
// Display widget
$oWidget->Display(..., $oLegacySet, ...);

An object can be archived before it is used by a module. As archiving is equivalent to a “soft deletion”, by default an archived object won't be returned by MetaModel::GetObject when archive mode is disabled. If it is enabled, then all archived objects are visible and there are no change to the previous behavior.

Here are the different behaviors depending on the $mustBeFound parameter values, when archive mode is disabled :

DBBackup::CreateZip is deprecated (remains available for a while) in favor of DBBackup::CreateCompressedBackup which produces a tar.gz.

DBRestore::RestoreFromZip is deprecated (remains available for a while) in favor of DBRestore::RestoreFromCompressedFile (which autodetects the format for backward compatibility).

When a field A (model) is dependent on a field B (brand) and there is a filter on A (SELECT Model WHERE brand=this→brand), when you edit the object:

• if the existing value of A is not coherent with the filter and the B value, it is no more removed

• if the field B is modified, A is reset as before

On 'resolved' ticket on Portal the caller can only Re-open or Close, no more modify by default

New parameters available in Configuration File, to prevent adding/removing attachment on closed ticket.

Starting with version 2.3.4, the Replica Table created by a dataSynchro, use a VARCHAR(10) format instead of DATE for date columns.

This change was made to enable the possibility to empty a date column using synchro_import when MySQL setup does not accept 0000-00-00 date value.

In the Replica Table

• a NULL value has the meaning Ignore this column so don't update the destination object.
• an empty string means empty the destination object field (force a reset of a value),
• a 0000-00-00 date value meant reset the date value, but this does not work with many MySQL setup (so we switch to string format)