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.

For security reasons, the use of REST/JSON webservices by user accounts with the profile 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>
latest/install/203_to_210_migration_notes.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1
Back to top
Contact us