2.2.x向2.3.x升级

iTop的版本2.3.0与先前的2.x版本（2.2.1、2.2.0、2.1.0、2.0.3、2.0.2…）完全向后兼容。但是，此版本引入了许多重大更改。

要求

的PHP

现在需要PHP 5.3.6。

支持的Web浏览器

不再支持Internet Explorer 8。

不再需要Flash Reader。

nsions兼容性

• 以下扩展与iTop 2.3.0不完全兼容（它们不支持R格式）
• 工单从发送邮件创建-直到版本包括2.6.12
• 发送邮件答复-直到包括版本1.1.7

如果您当前正在使用这些扩展，请在升级iTop时确保您使用升级扩展名。

通知事项

电子邮件正文现在通过带有以下限制.

为了安全起见，不允许将主体编辑为纯HMTL，并且每次编写主体模板时都会对其进行清理。

因此，无法再在发送邮件的模板中指定CSS格式。

无论如何，关于案例日志的格式，iTop会为您进行格式化。不过，您可以通过配置设置覆盖CSS样式表发送邮件_css.

额外好处：这个新的实施构建的电子邮件将在GMail和MS Outlook中正确格式化。

XML自定义

XML格式已升级为版本1.3.

此格式引入了三种新的属性类型：AttributeMetaEnum，AttributeCustomFields和AttributeImage。

OQL

过去必须以“反向”顺序编写一些查询。这是由于iTop处理带有分层键的查询的方式的限制。

例如，取自Person的location_id外键：

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

“反向”顺序是指这样的事实：针对获取位置而编写查询的“自然”方式是开始写“ SELECT Location JOIN Organization…”，而“反向”顺序看起来像是“ SELECT Organization FROM Organization JOIN Location” …）”。

从iTop 2.3.0开始，发生了两件事：

限制已解除：可以在任何方向（子级JOIN根或根级JOIN子级）写入分层查询。

另一个限制出现了：现代的Customer Portal使用查询交叉机制，其实现假定所有“相交”查询按自然顺序书写。

因此，现在强烈建议以自然顺序编写所有查询，即查询的类应该是所有联接的类中声明的第一个类。

示例（与前面的示例相同的来源）：

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

开发人员专区

如果您通过一些PHP代码自定义了iTop，则本章非常有趣。

启用RTF编辑器

从iTop 2.3开始，用户可以设置票证的字段说明和public_log的格式，并使用WYSIWYG编辑器将​​图像集成到文本中。

这种用于案例日志的所见即所得编辑器（CKEditor）的集成直接在文件portal / index.php中执行。如果您已经创建了该文件的自己的版本（通过克隆/修改以前的版本），则必须复制此集成。在portal / index.php中查找字符串.ckeditor（以获取有关此集成的详细信息。

此外，要通过复制和粘贴或使用图像上载按钮将图像嵌入字段中，您将拥有在正在创建创建/更新表单的任何地方插入以下代码段：

$oP->add_ready_script(InlineImage::EnableCKEditorImageUpload($oRequest, utils::GetUploadTempId($oP->GetTransactionId())));

请参考portal / index.php的当前代码以了解该代码必须插入的位置。要检查代码段是否有效，请加载表单，并检查是否没有显示“ [CKEditor]错误代码：upload-image-config”的JavaScript错误。

级联案例日志更新时保留格式

请检查是否有一些自定义代码调用verb.ormCaseLog :: GetModifiedEntry（）。

如果您已经克隆了任何工单类（其中标准实施会对案例日志中进行的级联更改）克隆到子日志或父工单中，则可能是这种情况。

对于GetModifiedEntry（）的每种用法，请考虑将其用于此文本：

-纯纯文本：不要使用变更，默认行为是返回纯文本，这没有改变。 -HTML文本应为：$ oCaseLog→GetModifiedEntry（'html'）

原贴链接：https://www.itophub.io/wiki/page?id=2_7_0%3Ainstall%3A220_to_230_migration_notes

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

The following extensions are not fully compatible with iTop 2.3.0 (they do not support rich text formatting)

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

Additional benefit: this new implementation builds emails that will be correctly formatted in GMail and MS Outlook.

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:

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

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