2.0.3 to 2.1.0 Migration Notes
The upgrade from 2.0.3 to 2.1.0 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:
Usability
The following change may have an impact on the user experience:
-
An extra menu “Excel export…” is available to export any list of elements. For more information, refer to: Managing Lists in the end-user documentation.
REST/JSON API
Check the REST/JSON Documentation for the latest version of the API.
The API is stable in this revision.
Portal User
will 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
core/check_credentials
operation.Data Model Customizations
The format of the XML has changed from 1.0
to
1.1
in the datamodel definition. The changes in the
XML format are transparent since the new format is fully backward
compatible. The complete list of format changes is listed in the
XML Data Model
Reference
Class groups in Profile definitions
The behavior of the profiles is exactly the same in iTop 2.0.3 and iTop 2.1.0. However, a cleanup has been performed on the internal names of “groups” used to define the profiles. Therefore customization based on the former group names may be incompatible with iTop 2.1.0.
There are two ways to address this issue:
-
Quick and dirty fix: simply replace the folder
datamodels/2.x/itop-profiles-itil
by its previous version extracted from iTop 2.0.3. -
Clean migration: analyse your XML customization and adjust it based on the changes listed below:
2.0.3 Groups | 2.1.0 Groups |
---|---|
Incident and
class:Incident |
Merged into Incident |
Call and
class:UserRequest |
Merged into UserRequest |
Problem and
class:Problem |
Merged into Problem |
LnkTickets |
Renamed into Ticketing |
class:EmergencyChange |
Renamed into EmergencyChange |
class:RoutineChange |
Renamed into RoutineChange |
class:NormalChange |
Renamed into NormalChange |
LnkServices |
Removed |
LnkKnownErrors |
Removed |
Portal user - write |
Removed |
Portal user - delete |
Removed |
-
Renamed groups: simply adjust the XML in your module by replacing the old name with the new name.
-
Merged groups: this can be treated as a rename: simply adjust your customization by replacing the name of the group with the named of the merged-in group.
-
Removed groups: such groups were actually not used by the definition of the profiles. If your customization was modifying the content of these groups, you can completely remove this from your customization. If your customization was adding such a group to an existing profile or defining a new profile based on such a group, you'll have to import the previous definition of the group (extracted from iTop 2.0.3) into your customization.
Inherited state flags
The version 2.1.0 of iTop supports a new XML tag
<inherit_flags_from>parent_state</inherit_flags_from>
.
This tag tells iTop that the flags from the current state are
inherited from the specified parent_state
. This allows
for a much more compact definition the flags (which is also easier
to maintain). But this refactoring may have an impact on the
alterations applied to the standard data model, since it changes
the structure of the XML.
As an example of “factorization” of the flags definitions for the life-cycle states, the following XML part can be changed from:
<state id="new"> <flags> <attribute id="org_id"> <mandatory /> </attribute> </flags> </state><state id="assigned"> <flags> <attribute id="org_id"> <mandatory /> </attribute> </flags> </state>
to:
<state id="new"> <flags> <attribute id="org_id"> <mandatory /> </attribute> </flags> </state><state id="assigned"> <inherit_flags_from>new</inherit_flags_from> <flags /> </state>
The net effect is that the actual definition of the flags for
the attribute org_id
has disappeared from the
assigned
state in the refactored version of the
XML.
If your XML alteration of the data model contains a
redefinition of the flags at the attribute level, then you
must change the _delta=“redefine”
into a
_delta=“define”
to obtain the same effect in iTop
2.1.0
Example: pre-2.1.0 alteration of the data model:
<state id="assigned"> <flags> <attribute id="org_id" _delta="redefine"> <hidden /> </attribute> </flags> </state>
The same alteration written in a manner compatible with iTop 2.1.0, will be:
<state id="assigned"> <flags> <attribute id="org_id" _delta="define"> <hidden /> </attribute> </flags> </state>
GetIcon/MakeIconFromName
The method MakeIconFromName
has been
deprecated.
If your customizations include a redefinition of
GetIcon
, which used to call
MakeIconFromName
, then insert the following XML right
above the overload of GetIcon:
- make_icon_from_name.xml
-
<method id="MakeIconFromName" _delta="define"> <static>true</static> <access>protected</access> <type>Overload-DBObject</type> <code><![CDATA[ protected static function MakeIconFromName($sIconName, $bImgTag = true) { $sIcon = ''; if ($sIconName != '') { $sPath = utils::GetAbsoluteUrlModulesRoot().'itop-request-mgmt/images/'.$sIconName; if ($bImgTag) { $sIcon = "<img src=\"$sPath\" style=\"vertical-align:middle;\"/>"; } else { $sIcon = $sPath; } } return $sIcon; }]]></code> </method>