2.2.x to 2.3.0 Migration Notes
The version 2.3.0 of iTop is fully backward compatible with the previous 2.x versions (2.2.1, 2.2.0, 2.1.0, 2.0.3, 2.0.2…), however this version introduces quite a few significative changes.
Requirements
PHP
PHP 5.3.6 is now required.
Supported Web browsers
Internet Explorer 8 is NOT supported anymore.
A Flash Reader is not required anymore.
Extensions compatibility
-
Ticket Creation from Email - until version 2.6.12 included
-
Email Reply - until version 1.1.7 included
If you are currently using these extensions, make sure that you upgrade the extension when upgrading your iTop.
Notifications
The body of emails are now configured by the mean of a GUI with the following restrictions.
For safety purposes, it is not allowed to edit the body as plain HMTL, and the body template gets cleaned whenever it is written.
As a consequence, it is no more possible to specify CSS formatting within the template of an email.
Anyhow, regarding the formatting of case logs, iTop does the formatting for you. Still, you may override the CSS stylesheet through the configuration setting email_css.
XML customizations
The XML format has been upgraded to version 1.3.
This format introduces three new types of attributes: AttributeMetaEnum, AttributeCustomFields and AttributeImage.
OQL
It used to be mandatory to write some queries in the “reverse” order. This was due to a limitation in the way iTop was handling the queries with hierarchical keys.
Example, taken from the location_id external key on a Person:
SELECT l FROM Organization AS child JOIN Organization AS root ON child.parent_id BELOW root.id JOIN Location AS l ON l.org_id=root.id WHERE child.id=:this->org_id
The “reverse” order refers to the fact that the “natural” way of writing a query aiming at fetching Location is to start writing “SELECT Location JOIN Organization…”, while the “reverse” order looks like “SELECT Location FROM Organization JOIN Location …)”.
Starting with iTop 2.3.0, two things have changed:
-
the limitation has been lifted: hierarchical queries can be written in any direction (child JOIN root, or root JOIN child)
-
another limitation appears: the modern Customer Portal uses a query intersection mechanism, and its implementation assumes that all of the “intersected” queries by written in the naturel order.
As a consequence, it is now highly recommended to write all the queries in the natural order, i.e. the queried class should be the first class declared amongst all the joined classes.
Example (same source as the previous example):
SELECT Location AS l JOIN Organization AS root ON l.org_id=root.id JOIN Organization AS child ON child.parent_id BELOW root.id WHERE child.id= :this->org_id
Developers corner
This chapter is of interest if you have customized your iTop by the mean of some PHP code.
Enable the rich text editor
Starting with iTop 2.3, users can format the Ticket's fields description and public_log and integrate images inside the text using a WYSIWYG editor.
The integration of this WYSIWYG editor (CKEditor) for case
logs is performed directly in the file
portal/index.php
. If you have made your own version of
this file (by cloning/modifying a previous version), you will have
to replicate this integration. Look for the string
.ckeditor(
in portal/index.php
for
details about this integration.
Moreover, to enable the embedding of images within fields, either by the mean of a copy and paste or by using the image upload button, you will have to insert the following snippet, anywhere a creation/update form is being built:
$oP->add_ready_script(InlineImage::EnableCKEditorImageUpload($oRequest, utils::GetUploadTempId($oP->GetTransactionId())));
Please refer to the current code of
portal/index.php
to understand where that code must be
inserted.
To check that the snippet is effective, load the form and check that there is no javascript error saying “[CKEditor] Error code: upload-image-config”.
Preserve formatting when cascading case log updates
Please check if you have some custom code that calls the verb
ormCaseLog::GetModifiedEntry()
.
This is problably the case if you have cloned any of the ticket classes, where the standard implementation does cascade changes made on a case log, to the child or parent ticket logs.
For each usage of GetModifiedEntry()
, consider the
usage of that will be made of this text:
- Pure plain text is expected : do not change anything, the
default behavior is to return a plain text, this has not changed. -
HTML text is
expected : go for
$oCaseLog→GetModifiedEntry('html')