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.

PHP 5.3.6 is now required.

Internet Explorer 8 is NOT supported anymore.

A Flash Reader is not required anymore.

If you are currently using these extensions, make sure that you upgrade the extension when upgrading your iTop.

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.

The XML format has been upgraded to version 1.3.

This format introduces three new types of attributes: AttributeMetaEnum, AttributeCustomFields and AttributeImage.

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:

1. the limitation has been lifted: hierarchical queries can be written in any direction (child JOIN root, or root JOIN child)
2. 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

This chapter is of interest if you have customized your iTop by the mean of some PHP code.

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”.

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')