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.

If you upgrade from the 2.2.0-beta version, make sure that the value 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 the bulk_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.

Beware if you customized the profiles: for security reasons, the bulk export is now only allowed to users having the 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);
If the page is not designed to be accessed by 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.

For security reasons, the use of REST/JSON webservices by user accounts with the profile 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.
Beware if you customized the profiles: for security reasons, the operations 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.
latest/install/210_to_220_migration_notes.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1
Back to top
Contact us