The version 3.0.0 of iTop is roughly backward compatible with previous 2.x versions, except extensions bringing specific displayed pages.
This document highlights issues which can occur while migrating your iTop to this version.
This version has a major impact on users habits. Check the
What's new document for all the changes impacting the ways things used to be done in the past and how they should be done in 3.0.
must_prompton the transition. As before, an empty mandatory field, is automatically prompted, even without an explicit flag
We have added a field
user_id in table CMDBChange to identify users who made the change.
priv_change, it took 5 sec to add
user_idto the table during upgrade setup.
If you have developed custom extensions with XML and custom code, check: Developer check-list
Check for each of your Combodo extensions the 3.0 compatible version that you need to install, before upgrading.
Be cautious, the 3.0 compatible version may not be available yet, also the version number is already known.
Those features are now included in iTop 3.0 so in general no more needed as additional standalone extensions
|Menu Finder||Function mirrored and included in iTop Community 3.0|
|Attributes visual beautifier||Feature provided in 3.0 for console only, extension still required on portal(s)|
|Attribute tooltip||Function mirrored and included in iTop Community 3.0|
|Bubble caselogs||Function mirrored and included in iTop Community 3.0|
|Disable Global Search|| Function mirrored with a Configuration parameter
|Multiple LDAP||Module included in iTop Community 3.0|
If you have customized a theme in XML, you must change it to follow the new 3.0 standard: Theme Customization, especially
2.7 theme customization variables are probably obsolete, see above page to migrate your theme.
If you have created a new theme from scratch in XML, then
<stylesheets> <stylesheet id="fullmoon" _delta="define">../css/backoffice/main.scss</stylesheet> </stylesheets>
dependencies node of the
manager_id has been removed as there was no usage of
org_id in the default OQL filter. It's probably from a time where Manager was limited to the organization of the Person.
If you removed or redefined it, you will need to adapt your XML.
<itop_design> <classes> <class id="Person"> <fields> <field id="manager_id"xsi:type="AttributeExternalKey"> <filter><![CDATA[SELECT Person]]></filter> <dependencies> <attribute id="org_id"/> </dependencies> </field> </properties> </class> </classes> </itop_design>
If you have a Combodo Product or installed Mail to Ticket Automation: check that Users which must be able to access the Mailbox, can still do it, and if not change their Profile(s)
class:EmailReplica are now by default not visible to non-administrator, unless explicitly granted with read access, through a profile (internally, category was changed from
This was an old and unused feature from iTop 2.0 which we decided to completely remove during the backoffice rework. It means that if you used the `display_template` property of a (PHP or XML) class to display its form differently, it won't work anymore in iTop 3.0, the standard form will be displayed instead.
To ease the migration, the application will upgrade safely if the property is still present in the XML / PHP (it will be silently ignored). Even though it is not mandatory for the migration, we recommend that you remove any usage of this feature.
<itop_design> <classes> <class id="UserRequest"> <properties> <display_template _delta="redefine">my-module/my-template.html</display_template> </properties> </class> </classes> </itop_design>
Before running unattended installation you have to list the “additional modules to select” inside the XML file provided to the
<?xml version="1.0" encoding="UTF-8"?> <installation> <selected_modules type="array"> <item>itop-structure</item> <item>itop-bridge-cmdb-ticket</item> ... </selected_modules> ... </installation>
For more information regarding unattended installation: https://wiki.combodo.com/doku.php?id=latest:advancedtopics:automatic_install&s=unattended#unattended_installat
When you change the allowed values of an enum through an iTop extension while you have objects in your iTop instance which still used the old values, the Setup used to fail, with a Fatal Error.
But it is no more the case, because the database allowed values for the enum, is the union of the datamodel values and the values in use when the last Setup was performed. So as long as a value is in use, even if not in the datamodel defined values, it will be kept in database.
In the iTop User Interface,
Database integritytool will reports those objects having an invalid value on one of their enum
1-high,2-medium,3-lowto get a nice automatic order in list and dashlets
id (primary key)and the enum label
id (primary key)and the enum label
Database integritymenu to ensure you have completed the data migration
Below is a list of the deprecated configuration parameters, this mean that they will no longer have any effect in the application.
buttons_position: Object form buttons are now always at the top of it.
We removed a bunch of images from iTop, if you used them you'll need to replace them with their new SVG equivalent which are in the same folder.
datamodels/2.x/ itop-attachments/icons/ doc.png document.png html.png image.png movie.png odb.png odg.png odp.png ods.png odt.png one.png pdf.png ppt.png txt.png xls.png zip.png
Some of the images included in the datamodel's modules have been replaced with new SVG files which:
Most of them can be found
images/icons. Icons specific to a class state can be found in the corresponding module's images folder.
The old PNG files are still present to ease the migration but will be removed in the next version.
datamodels/2.x/ itop-change-mgmt/images/*.png itop-change-mgmt-itil/images/*.png itop-config-mgmt-itil/images/*.png itop-datacenter-mgmt/images/*.png itop-endusers-devices/images/*.png itop-faq-light/images/*.png itop-incident-mgmt-itil/images/*.png itop-knownerror-mgmt/images/*.png itop-problem-mgmt/images/*.png itop-request-mgmt/images/*.png itop-request-mgmt-itil/images/*.png itop-service-mgmt/images/*.png itop-service-mgmt-provider/images/*.png itop-storage-mgmt/images/*.png itop-structure/images/*.png itop-tickets/images/*.png itop-virtualization-mgmt/images/*.png itop-welcome-itil/images/*.png
The triggers are now called AFTER the database update (instead of before). The requests used to filter the triggers will behave differently than in iTop 2.7, if one of the
Target fields is used in the where condition of the OQL
Before the migration to 3.0, the current object was not yet saved in Database with its new values, so the filter was written to include the current object based on its previous values.
Trigger On Object Updateif it uses a condition on an updated field
Example, where the field “priority” is used in the WHERE clause of the
Filter and is part of the
On such Trigger, the
Filter must be changed, because it won't be triggered in the same situation as before migration.
In the console (backoffice):
Here is how you can customize the logos.
You have created your new MenuGroup, you may want to set an icon. For Combodo's customer, this can be done in the ITSM Designer
You have created your own class, you may want to change the icon. For Combodo's customer, this can be done in the ITSM Designer
You have modified the possible values for User Request status and priority, you may want to highlight status for the new status (and the standard ones). For Combodo's customer, this can be done in the ITSM Designer.
The selected caselog when opening/editing an object is always the first one. We have changed the datamodel to reflect this, but if you have overwritten the XML presentation of the UserRequest or the Incident classes, you won't get our fix, and most probably you will have to reorder the caselogs this way:
<!-- [...]--> <item id="col:col2"> <items> <item id="fieldset:Ticket:relation"> <items> <item id="parent_request_id"> <rank>10</rank> </item> <!-- [...]--> </items> <rank>30</rank> </item> <item id="public_log"> <rank>34</rank> </item> <item id="private_log"> <rank>38</rank> </item> <item id="functionalcis_list"> <rank>40</rank> </item> <item id="contacts_list"> <rank>50</rank> </item> <!-- [...]-->
The same applies to the presentation of the Incident class.
If you have access to the ITSM Designer, check the details presentation and add the caselogs to it, in the desired order.
With the new activity panel came a few parameters to tune it:
activity_panel.datetimes_reformat_limitto go back to previous absolute format for every entries.
activity_panel.show_author_name_below_entriesallows to display the name of the author below the date. Otherwise, a tooltip over the user icon displays their name as well.
mentions.allowed_classes. You may create a Trigger to limit the proposed objects, but you aren't forced to define a notification for each trigger.
Since the introduction of the activity panel in the backoffice, the origin of the CMDBChanges (history entries) are now displayed when it wasn't done in a classic form in the GUI (eg. Webservices, email processing, custom extension, CSV import, …)
In iTop 2.7 and older, the origin of the CMDBChanges made through the CSV import in the backoffice were marked as “interactive” when they should actually be marked “csv-interactive”. This has been fixed in iTop 3.0 but only for the CMDBChanges made AFTER the migration, meaning that the old history entries made via the CSV import page won't appear like it.
Unfortunately there is no easy way to correct the previous entries on the DB.
In iTop 2.7 and older, the origin of the CMDBChanges made through the “Mail to ticket automation” extension were marked as “custom-extension” when they should actually be marked “email-processing”. This has been fixed in iTop 3.0 but only for the CMDBChanges made AFTER the migration, meaning that the old history entries made via the extension won't appear like it.
If you would like to the previous entries in the DB, you can run the following query, but keep in mind that it can take a very long time as this table is one of the most important in the DB.
<DB_TABLE_PREFIX>by the values used in your iTop configuration before running the query.
UPDATE <DB_SHEMA>.<DB_TABLE_PRFIX>priv_change SET origin = 'email-processing' WHERE userinfo = 'Mail to ticket automation (background process)';
Before downgrading from 3.0.0 to a 2.7 iTop version
MariaDB [demo]> DELETE priv_link_action_trigger FROM priv_link_action_trigger LEFT JOIN priv_trigger ON priv_link_action_trigger.trigger_id=priv_trigger.id WHERE priv_trigger.realclass='TriggerOnObjectMention'; MariaDB [demo]> DELETE priv_trigger, priv_trigger_onobjmention FROM priv_trigger INNER JOIN priv_trigger_onobjmention ON priv_trigger.id=priv_trigger_onobjmention.id;
MariaDB [demo]> DELETE FROM priv_module_install WHERE name='datamodel' AND version LIKE '3.0%';