2.0.2 to 2.0.3 Migration Notes
The upgrade from 2.0.2 to 2.0.3 should be totally transparent to your end-users. However a few things changed between the two versions. Depending on the way you use the application you may want to pay special attention to the following points:
The following change may have an impact on the user experience:
The global search now requires the end-user to type at least 3 characters. There was no such limitation previously. This limit (3 characters) is configurable via the configuration parameter
Check the REST/JSON Documentation for the latest version of the API. The following changes may have an impact on your integrations:
The output of the
core/deleteoperation has changed. The operation now properly reports what was done.
The handling of “CaseLog” attributes has been improved. The output format now reflects the structure of the case log (one item per entry in the case log), and, in input it is now possible to add several items to a case log or even completely replace it.
A new operation
core/check_credentialshas been introduced… to check the credentials of a given user.
The output of boolean attributes changed: it was “1” (meaning true) and “” (empty string, meaning false) previously, it is now “1” (meaning true) and “0” (meaning false).
The value returned for Enumerated fields (like the status of a ticket) is now always the 'code' (i.e. a non-translated value) and no longer the localized label.
Portal Userwill be disabled in the next major version of iTop. If you use one of the webservices only to check the credentials of a user, adjust your code to use the new
Data Model Customizations
If you performed your own customizations to the iTop data model, pay attention to the following changes:
The definition of the menu for “Admin tools / Query Phrasebook” changed to add the search form at the top. If you have implemented your own menus (normally defined in itop-welcome-itil module), make sure that you update the menu definition to show the search form at the top as well.
For performance reasons, the default
tracking_levelon link sets has been changed. Unless specified otherwise in the data model, the default behavior is now to disable the history tracking of 1:n links for fresh installations.
During the upgrade, the setup process will perform a cleanup of
unused records in the history tracking. Depending on the size of
priv_change table and the number of unused records
to remove, this may take several minutes.