2.1.0 to 2.2.0 Migration Notes
The version 2.2.0 of iTop is fully backward compatible with the previous 2.x versions (2.1.0, 2.0.3, 2.0.2…), however this version introduces quite a few significant changes.
New prerequisites for installing iTop: PHP 5.3.0 (instead of 5.2.0) with the Zip extension and Graphviz.
query_cache_enabledis not set to
falsein the iTop configuration file. If so, please either change the value to
trueor completely remove the line from the configuration file. Letting the value set to
falsewill cause a severe slow down of the application.
The following changes may have an impact on the user experience:
The color scheme of the application has changed to be aligned with Combodo's new branding.
The interactive export has been reworked to provide a better flexibility and additional output formats.
The impact analysis diagram is no longer using Flash and now offers additional context information, but looks quite different.
Only users with the rights
bulk_readare now allowed to perform bulk exports. (By default in iTop everyone has the
Admin tools / Export now points to the
export-v2.php. This page can be used either in
interactive mode or in scripted mode (both from the web or the
command line interface).
The main change since the previous version of iTop is that the new export takes into account the order of the fields to export and supports more formats (the xlsx and PDF format are fully supported with some format specific options).
We encourage you to test your existing scripts against the new
export-v2.php page in replacement of
export.php and to migrate them if possible.
export.php is still available, unmodified,
for 100% backward compatibility.
bulk readprivilege on the specified class of objects. This applies to the
export-v2.phppages. However this is transparent in the default iTop model, since all users are granted this privilege.
The XML format has been upgraded to version 1.2.
This new version supports the definition (and alteration) of the relations (e.g. impacts or depends on) in XML.
If you customized such relations (via the
GetRelationQueries() method in PHP), we encourage you
to migrate to the XML definition which is more flexible and
supports the definition of redundancy rules.
Nevertheless the overload of the method
GetRelationQueries() is still supported in iTop
Due to this change, and if you have removed attributes by the mean of customizations, you might need to adjust your XML.
Here is the list of attributes which removal requires additional adjustments:
|FunctionalCI||contacts_list, applicationsolution_list, softwares_list|
|LogicalVolume||s ervers_list, virtualdevices_list|
Example: Let's assume that you have removed the attribute FunctionalCI::applicationsolution_list.
You will have to remove the corresponding relation path:
<itop_design xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2"> <classes> <class id="FunctionalCI"> <relations> <relation id="impacts"> <neighbours> <neighbour id="applicationsolution" _delta="delete"/> ...
Failing to do so will result in the following error, when requesting the “details” of any type of object:
Wrong definition for the relation impacts/FunctionalCI/applicationsolution: Unknown attribute applicationsolution_list from class FunctionalCI
You must upgrade your toolkit to iTopDataModelToolkit-2.2.zip. That version remains backward compatible with older versions of iTop.
For PHP developers, be aware of the following change: the new
base class for all “searches” is now the abstract class
DBSearch. This new class has two child classes: the
DBObjectSearch and the new
Check your custom functions/methods: whenever the argument is
DBObjectSearch, it is recommended to change
DBSearch. This ensures that your code will still
work if the passed query is of type
(which corresponds to the new capability introduced in 2.2.0: UNION
Pages authentication and custom portals
In order to support custom portals, the API
LoginWebPage::DoLogin slightly changed. Therefore the
authentication of all pages which are supposed to accept
Portal Users must be changed from:
LoginWebPage::DoLogin(false /* bMustBeAdmin */, true /* IsAllowedToPortalUsers */);
LoginWebPage::DoLoginEx(null /* any portal */, false);
Portal Users, then the appropriate authentication code is:
LoginWebPage::DoLogin(false /* bMustBeAdmin */, false/* IsAllowedToPortalUsers */);
Check the REST/JSON services documentation#changes_history for the latest version of the API.
Portal Useris now disabled. If you use one of the webservices only to check the credentials of a user, adjust your code to use the new
core/get_relatedare now only allowed to users having the
bulk readprivilege on the specified class of objects. However this is transparent in the default iTop model, since all users are granted this privilege.