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.

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.

Internet Explorer 8 is NOT supported anymore.

A Flash Reader is not required anymore.

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