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_enabled
is not set to
false
in the iTop configuration file. If so, please
either change the value to true
or completely remove
the line from the configuration file. Letting the value set to
false
will cause a severe slow down of the
application.Usability
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_read
are now allowed to perform bulk exports. (By default in iTop everyone has thebulk_read
rights).
Export
The menu Admin tools / Export
now points to the
page 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.
The old export.php
is still available, unmodified,
for 100% backward compatibility.
bulk read
privilege on the
specified class of objects. This applies to the
export.php
and export-v2.php
pages.
However this is transparent in the default iTop model, since all
users are granted this privilege.XML customizations
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
2.2.0.
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:
Class | Attribute |
---|---|
FunctionalCI | contacts_list, applicationsolution_list, softwares_list |
ApplicationSolution | businessprocess_list |
Middleware | middlewareinstance_list |
DBServer | dbschema_list |
WebServer | webapp_list |
Enclosure | device_list |
StorageSystem | logicalvolume_list |
SANSwitch | datacenterdevice_list |
TapeLibrary | tapes_list |
NAS | nasfilesystem_list |
LogicalVolume | s ervers_list, virtualdevices_list |
VirtualHost | virtualmachine_list |
Hypervisor | farm_id |
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
Module Developers
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
former DBObjectSearch
and the new
DBUnionSearch
.
Check your custom functions/methods: whenever the argument is
typed as DBObjectSearch
, it is recommended to change
it to DBSearch
. This ensures that your code will still
work if the passed query is of type DBUnionSearch
(which corresponds to the new capability introduced in 2.2.0: UNION
queries).
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 */);
to:
LoginWebPage::DoLoginEx(null /* any portal */, false);
Portal
Users
, then the appropriate authentication code is:
LoginWebPage::DoLogin(false /* bMustBeAdmin */, false/* IsAllowedToPortalUsers */);
REST/JSON API
Check the REST/JSON services documentation#changes_history for the latest version of the API.
Portal User
is 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/check_credentials
operation.core/get
and core/get_related
are now
only allowed to users having the bulk read
privilege
on the specified class of objects. However this is transparent in
the default iTop model, since all users are granted this
privilege.