2.3.x to 2.4.0 Migration Notes
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
To check before upgrading
Archiving
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
Obsolescence
user
preference
have been set to not show
obsolete data
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
'obsolescence.show_obsolete_data' => true,
Obsolescence criteria on a CI cannot depends on a parent class of the current CI
Example: changing DatabaseSchema
dbserver_id
from
a DBServer ExternalKey to a FunctionalCI ExternalKey, because we
want the server to be either a DBServer or ClusterServer, leads to
an infinite loop in the DatabaseSchema obsolescence
computation.More on obsolescence
Overriden DisplayBareRelations method
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:
CMDBObjectSet::SetShowObsoleteData(utils::ShowObsoleteData());
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);
Flags on transition
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 fromassigned
toassigned
state,agent_id
is required to be changed. -
on an
assigned
state, theagent_id
is read only.
portal: forms en transition
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.
New Backup format
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.
Also note that \DBBackup::CreateZip is kept in the code but marked as deprecated. It will be removed in 2.7.0.
Legacy portal
Legacy portal is now deprecated and will be removed as of iTop 2.7.0.
Enhanced portal
User Profile Brick
New Search Brick
Extensions
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
Customizations
DBObject::GetDefaultValue
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/Set
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);
UILinksWidget/UILinksWidgetDirect::Display
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, ...);
MetaModel::GetObject
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 :
Object type | $mustBeFound value | return |
---|---|---|
Non archived object | true | object |
Non archived object | false | object |
Archived object | true | ArchivedObjectException |
Archived object | false | null |
Non existing object | true | CoreException |
Non existing object | false | null |
Backup/Restore
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).
Details: keep existing value
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
Lifecycle
On 'resolved' ticket on Portal the caller can only Re-open or Close, no more modify by default
Attachment
New parameters available in Configuration File, to prevent adding/removing attachment on closed ticket.
Data Synchro
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)