2.6.x向2.7.x升级

iTop的版本2.7.0大致与以前的2.x版本向后兼容,但有一些显着的变化。

本文档重点介绍了将iTop迁移到版本时可能发生的问题。

  • 要重点关注新功能,请检查什么是新的 
  • 有关更改的详尽列表,请检查变更日志 

用户上的影响度

  • 对于在其用户上设置了“允许的组织”的用户,返回多个类别的对象的OQL查询可能在升级之后返回较少的数据。这是由于查询代已修复。

门户行为更改

  • 现在可以单击表单中的外部键显示,如果您希望保留以前的行为,则将表单中的xxx_id属性代码替换为xxx_id_friendlyname。
  • 我们已经将Font Awesome从v4更新到v5.12.0,请检查门户中的图标是否仍按预期显示。一些图标名称已更改 在两个版本之间,旧名称仍然可以使用,除非您使用了版本4中的别名,这需要进行更改。
  • 由于安全的原因,默认情况下,以表格形式显示的LinkedSet(例如与用户请求关联的联系人)现在仅限于门户用户的范围。那里的一个典型示例是门户用户可以在他的用户请求中看到IT部门关联的联系人,即使从理论上讲他的联系人范围只能将他限制为自己的组织的联系人。如果要保留以前的行为,则需要修改门户用户中显示这些链接集的表单,如门户XML引用中的2.7新功能 

变更适用于管理员用户

  • 理工具已被修改,其某些条目已移至新的配置和系统菜单。
  • 用户对象中“人员”字段的标签已更改。这将使变更在CSV和excel导出用户中得到:
旧标签新标签
Contact (person)->First NamePerson->First Name
Contact (person)->Last NamePerson->Last Name
Contact (person)->EmailPerson->Email

升级前检查

系统

  • 确保在iTop服务器上安装了php-gd.现在它是在安装时强制执行的,因为它是正确处理案例记录和描述中的图像所必需的。

如果您使用php-memcache,请迁移到php-memcached

数据库大小

此版本将增加数据库的大小

历史表和事件通知表每行将增加 1KB

例如,如果您有 100 万个历史记录条目,则需要 1GB 的额外磁盘空间,只用于历史记录

 SELECT COUNT(*) FROM priv_changeop;  /* History */
 SELECT COUNT(*) FROM priv_event;  /* Notification */

设置可能需要时间

升级到2.7生产版本会生成数据库更改,如果您有很多数据,则可能需要一些时间。

基本变化

中级班决赛

为了增加查询性能,我们在类分层中的每个中间表类上添加了一个用于存储最终类的新列(仅在中间类和根类上,该列已经存在,并且在最终类上,此列无用)是表名)。

因此,在安装过程中,对于每个中间类,iTop都会运行ALTER TABLE

Example
 
ALTER TABLE `priv_changeop_setatt` 
   ADD `optype` VARCHAR(255) CHARACTER 
      SET utf8mb4 COLLATE utf8mb4_unicode_ci 
      DEFAULT 'CMDBChangeOpSetAttribute', 
   ADD INDEX `optype` (`optype` (95))

并且在UPDATE表之后

UPDATE `priv_changeop_setatt`,`priv_changeop` 
   SET  `priv_changeop_setatt`.`optype` = `priv_changeop`.`optype` 
   WHERE `priv_changeop_setatt`.`id` = `priv_changeop`.`id` 

附件

为了存储创建日期和上传附件的用户,iTop安装程序会自动更新数据库架构,如下所示:

ALTER TABLE `attachment` ADD `creation_date` DATETIME, 
                         ADD `user_id` INT(11) DEFAULT 0, 
                         ADD INDEX `user_id` (`user_id`);

警告,如果您使用表前缀选项(db_subname iTop配置文件参数),则表名会有所不同。例如,使用db_subname ='myprefix',则表名将为:myprefix_attachment。

风险性

如果您有大量附件并且在对象上拥有悠久的历史,则此运维可能会花费很长时间。

  • ALTER TABLE的执行时间与表的大小大致成比例
  • UPDATE TABLE的执行时间主要受行数和表大小的影响。

执行时间示例

这是表大小和计数花费时间的示例:

执行
大小(GB)计数查询(开始)
572500001486ALTER TABLE`attachment`
7,332000000212ALTER TABLE `priv_changeop_setatt`
7,3320000002621UPDATE`priv_changeop_setatt`,
2,41760000132ALTER TABLE `priv_changeop_setatt_scalar`
2,41760000465UPDATE`priv_changeop_setatt_scalar`,
3,11266700096ALTER TABLE `priv_changeop_links`
3,1126670001076UPDATE`priv_changeop_links`,
1,7753100069ALTER TABLE`priv_event_notification`
1,77531000613UPDATE`priv_event_notification`,
0,814300036ALTER TABLE `priv_changeop_setatt_longtext`
0,814300054更新`priv_changeop_setatt_longtext`,

longqueriesmigration27.xlsx

 ALTER TABLE `priv_changeop_setatt` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttribute', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_setatt_scalar` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeScalar', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_setatt_longtext` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeLongText', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_links` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeLinks', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_event_notification` ADD `realclass` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'EventNotification', ADD INDEX `realclass` (`realclass` (95))  
 ALTER TABLE `attachment` ADD `creation_date` DATETIME, ADD `user_id` INT(11) DEFAULT 0, ADD INDEX `user_id` (`user_id`)  
 UPDATE `priv_changeop_setatt`,`priv_changeop` SET  `priv_changeop_setatt`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_setatt_scalar`,`priv_changeop` SET  `priv_changeop_setatt_scalar`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt_scalar`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_setatt_longtext`,`priv_changeop` SET  `priv_changeop_setatt_longtext`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt_longtext`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_links`,`priv_changeop` SET  `priv_changeop_links`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_links`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_event_notification`,`priv_event` SET  `priv_event_notification`.`realclass` = `priv_event`.`realclass` WHERE `priv_event_notification`.`id` = `priv_event`.`id`

减轻

要确定可能需要花费时间的表,可以使用已用真实的itop db名称修改的查询

SELECT TABLE_NAME AS "Tables", 
    round(((data_length + index_length) / 1024 / 1024), 2) AS SIZE 
  FROM information_schema.tables 
  WHERE table_schema =  'itop db name'
  ORDER BY SIZE

确保您的iTop服务器的可用磁盘空间至少具有最大表的大小

然后在生产数据库的副本上的测试环境上运行升级流程。 setup.log文件将为您提供运行的确切查询。

您可以在升级前在生产数据库上运行这些SQL查询!除了它可能在执行期间引起的性能降级之外,没有风险会破坏iTop,因为它只会忽略添加的列,直到您将升级更改为版本2.7为止。

如果您在给定的表上手动运行ALTER TABLE,请同时运行UPDATE查询,否则数据库将为含混的,而iTop 2.7将不起作用。
附件表没有更新查询。

设定流程

如果您的浏览器在设置数据库升级期间返回超时,请不要杀死Web服务器或数据库数据库。尽管有此浏览器消息,但安装程序仍在继续。

您可以连接到mysql来检查正在进行的查询,您将看到在当前查询上已经花费的时间,如果再次运行该命令,该时间将增加或显示下一个查询。

php>mysql -u root -p xxxx
mysql> processlist;

只要查询一直在进行,设置仍会继续进行。然后跑

tail -f setup.
 
2020-03-02 13:49:52 | Ok      | <---- Exiting read only mode | SetupLog

以确保安装结束。

如果您的浏览器超时,则说明安装未完成。确保数据库升级完成后,您必须再次运行安装程序,这一次它会更快,因为将不再执行数据库升级。

第二次iTop升级到2.7

重要的事情要知道您是否已回滚2.7 iTop升级,现在又想将同一iTop再次升级到2.7.0或2.7.1:

如果您将iTop的生产实例升级到2.7版本,则无论出于何种原因稍后将其降级到任何以前的版本。一切都会顺利进行,但是在您再次升级到2.7.0或2.7.1的那一天,在这种情况下,我们存在一个已知问题。要对其进行修复,必须运行数据库完整性菜单并直接在MySQL或MariaDB数据库上的SQL中手动进行修复,这是回滚间隔期间在iTop中创建的对象缺少的finalclass值。

门户

不兼容的扩展

由于Silex to Symphony迁移,以下扩展与iTop 2.7门户不兼容。新的版本将在2020年4月中旬发布,如果已将它们部署在iTop上,则必须在升级iTop之前将升级的扩展部署在iTop上。

如果您是Combodo客户,则使用iTop Professional或Essential:
这不适用于您!

门户上的自定义扩展

如果您有自定义的扩展在门户中引入了新的模块,则需要编写一个新的版本。

因为,为了确保更好的安全,支持和可持续性;我们将门户的框架从Silex 2.x迁移到了Symfony 3.4。即使我们设法保持了大多数代码的向后兼容性,但如果您为门户进行了自定义扩展,则很可能会对其一部分进行返工。

读这一页 检查是否与您的扩展有关。

原有的末端门户

正如宣布的那样,iTop 2.7中不再提供原有门户

XML数据模型

重大变化

iTop 2.7的XML默认数据模型包含一些更改,这些更改可能与您可能已经通过扩展在iTop数据模型上所做的更改发生冲突(如果您是Combodo客户,则使用ITSM设计器)。

这些冲突应在iTop安装过程中自动处理,如果不仔细阅读该消息,它将说明哪个XML节点发生故障。

品牌推广

  • 现在,默认主题包含在 /itop_design/branding/themes/theme[@id=“light-grey”],下,因此,如果更改了品牌节点,请确保将更改标记(例如_delta =“ define”)放在子节点上。
itop_design iTop 2.7.0
 
  <branding>
    <themes>
      <theme id="light-grey">
        ...

不再工作:

itop-design in MyExtension
 
  <branding _delta="define">
    <main_logo>
      <fileref ref="logo-combodo_f737e922334a6d51b0d98e9f590d2295"/>
    </main_logo>
    <login_logo>
      ...
  </branding>

兼容2.7:

itop-design in MyExtension
 
  <branding>
    <main_logo _delta="define">
      <fileref ref="logo-combodo_f737e922334a6d51b0d98e9f590d2295"/>
    </main_logo>
    <login_logo _delta="define">
      ...
  </branding>

原有客户门户

原有客户门户已弃用了几个版本,现已完全删除。如果您已经重新定义了它的某些常量或路由,则需要更正XML。

量:删除所有以“PORTAL_”开头的常量节点,因为它们不再存在。

itop_design iTop 2.6 and earlier
 
<constants>
    <constant id="PORTAL_POWER_USER_PROFILE">...</constant>
    <constant id="PORTAL_SERVICECATEGORY_QUERY">...</constant>
    ...
</constants>

路由:从门户legacy_portal中删除"文档"。

itop_design iTop 2.6 and earlier
 
<portals>
    <portal id="legacy_portal">
        ...
    </portal>
</portals>

客户门户

在 /itop_design/module_designs/module_design[@id=“itop-portal”]/forms/form[@id=“<FORM_ID>”]/属性下添加了导航规则,用于“ticket-create”,“ticket-edit”,“ticket-reopen”和“ticket-apply-stimulus”形式,因此,如果更改了属性节点,请确保将更改标志(eg_delta =“ define”)放在子节点上。

itop_design / module_designs / module_design / forms iTop 2.7.0
 
  <form id="ticket-create">
    <properties>
      <navigation_rules>
        <submit>
          <default>go-to-open-requests</default>
        </submit>
        ...

不再工作:

itop-design / module_designs / module_design / forms in MyExtension
 
  <form id="ticket-create">
    <properties _delta="define">
      <always_show_submit>true</always_show_submit>
    </properties>
      ...
  </form>

兼容2.7:

itop-design / module_designs / module_design / forms in MyExtension
 
  <form id="ticket-create">
    <properties>
      <always_show_submit _delta="define">true</always_show_submit>
    </properties>
      ...
  </form>

管理工具菜单

管理工具子菜单已移至新创建的组菜单配置和系统下。如果您已经重新定义了这些菜单,则可能无法按预期运行。

其他

  • 现在,新的GetTicketRefFormat()方法是工单| UserRequest |事件|问题|变更类的一部分,因此,如果添加了具有相同名称的自定义方法,则必须调整代码。

弃用

尽管这些没有破坏性的更改,但您应避免使用不建议使用的代码。这是2.7版本中引入的总结:

  • 您应该验证是否使用了不推荐使用的MetaModel :: GetNextKey,这种使用通常在/itop_design/classes/class/methods/method[@id='DBInsertNoReload']中完成
  • 门户:goto类型的功能规则应替换为导航规则。这意味着您的砖块中不应有功能规则,而在相应的表单中应有导航规则。适用于以下XPath的搜索:*

    /itop_design/module_designs/module_design/action_rules/action_rule/submit

    • /itop_design/module_designs/module_design/action_rules/action_rule/cancel

对于开发人员

用户权利适用于用户类

以前,获取用户对象实例的PHP代码正在查询数据库,而与当前的用户权利无关。在2.7.0中进行了更改。

但是,即使当前的用户在该类上没有权利,某些代码仍然需求可以访问用户类。为此,您需要变更您的代码才能使用AllowAllData选项。

“没有更多可用代码”和“适当修复”的两个示例:

MetaModel::GetObject

// before 2.7.0 this was working for non admin users
$oUser = MetaModel::GetObject('User', $iCurrentUserId);
 
// After 2.7.0 to search for objects of the User class 
// You need to explicitly specify to ignore current user rights on the User class
// Forcing the 4st parameter to true, bypass "current user rights"
$oUser = MetaModel::GetObject('User', $iCurrentUserId, true, true); 

Reference: MetaModel::GetObject

DBSearch::AllowAllData

// before 2.7.0 this was working for non admin users
$oFilter = DBSearch::FromOQL('SELECT User WHERE id = :id');
$oSet = new DBObjectSet($oFilter, (), ('id' => $iCurrentUserId));
$oCurrentUser = $oSet->Fetch();
 
// After 2.7.0 you should add this to get Users objects
// Despite current user doesn't have rights on the User class :
$oFilter = DBSearch::FromOQL('SELECT User WHERE id = :id');
$oFilter->AllowAllData(); // this method call will bypass user access rights
$oSet = new DBObjectSet($oFilter, (), ('id' => $iCurrentUserId));
$oCurrentUser = $oSet->Fetch();

参考: DBSearch::AllowAllData

ApplyStimulus已更改

如果该刺激不适用于当前状态的对象,则ApplyApptimulus()方法现在在返回false之前将其返回false,而不是true。

删除的图像

许多图像已被管理员中的“真棒字体”图标取代。安慰。那些不再使用的代码将从iTop软件包(/images folder)中删除。这意味着,如果您在扩展中使用它们,则应相应地使用变更。

images/actions_bkg.png
images/actions_left.png
images/asc.gif
images/help.png
images/home.png
images/menu.png
images/mini-arrow-orange-open.gif
images/mini-arrow-orange.gif
images/mini_add.gif
images/mini_search.gif
images/mini_tree.gif
images/newsroom-message.svg
images/newsroom_menu.png
images/on-off-menu.png
images/onOffBtn.png
images/pencil-menu.png
images/printableversion.png
images/reload.png
images/searchBtn.png
images/settings.gif
images/zoom.gif

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


2.6.x to 2.7.0 Migration Notes

The version 2.7.0 of iTop is roughly backward compatible with previous 2.x versions, with a few significative changes.

This document highlights issues which can occur while migrating your iTop to this version.

  • For a focus on new features check What's New

  • For an exhaustive list of changes check the Change Log

Impact on Users

  • OQL queries returning multiple classes of objects, may return less data after the upgrade, to users having “Allowed organizations” set on their user. This is due to a fix in query generation.

Portal behavior changes

  • External key display in forms are now clickable, if you rather keep the previous behavior replace the xxx_id attribute code in your form withxxx_id_friendlyname.

  • We have update Font Awesome from v4 to v5.12.0, check that your icons in portal are still displayed as expected. Some icons names have changedbetween the 2 versions, old name will still work except if you have used aliases from the version 4, which will need to be changed.

  • For security reasons, LinkedSet displayed in forms, such as for example contacts associated to a User Request, are now by default limited to the scope of the portal user. A typical example there, was that portal user could see on his User Requests, IT department associated contacts, even if in theory his Contact scope was limiting him to contacts of his own organization. If you want to keep the previous behavior, you need to modify the forms in your portal displaying those linksets as explained in the 2.7 new features in the Portal XML reference

Change for Administrators users

  • Admin tools has been modified and some of its entries moved to new Configuration and System menus.

  • Labels of Persons fields in User objects have been changed. This will change what you get in CSV and excel export of Users:

old labelnew label
Contact (person)->First NamePerson->First Name
Contact (person)->Last NamePerson->Last Name
Contact (person)->EmailPerson->Email

To check before upgrading

System

  • Ensure that you have php-gd installed on your iTop server. It is now enforced at setup, as it is mandatory for handling correctly images within caselogs and description.

If you use php-memcache, migrate to php-memcached

Setup can take time

The upgrade to the 2.7 product version, will generate database changes, which can take time if you have a lot of data.

Underlying changes

Finalclass on intermediate classes

To increase query performance, we are adding on each intermediate table/class within a class hierarchy, a new column to store the final class (Only on intermediate classes as on a root class this column exist already and on a final class, this column is useless as this is the table name).

As a result during Setup, for each of those intermediate classes, iTop runs an ALTER TABLE

Example
 
ALTER TABLE `priv_changeop_setatt` 
   ADD `optype` VARCHAR(255) CHARACTER 
      SET utf8mb4 COLLATE utf8mb4_unicode_ci 
      DEFAULT 'CMDBChangeOpSetAttribute', 
   ADD INDEX `optype` (`optype` (95))

and just after an UPDATE table

UPDATE `priv_changeop_setatt`,`priv_changeop` 
   SET  `priv_changeop_setatt`.`optype` = `priv_changeop`.`optype` 
   WHERE `priv_changeop_setatt`.`id` = `priv_changeop`.`id` 

Attachments

To store creation date and user having uploaded an attachment, iTop Setup automatically updates the DB schema, like this:

ALTER TABLE `attachment` ADD `creation_date` DATETIME, 
                         ADD `user_id` INT(11) DEFAULT 0, 
                         ADD INDEX `user_id` (`user_id`);

Warning, if you're using the table prefix option (db_subname iTop config file parameter) the table name will vary. For example with db_subname='myprefix' then the table name would be : myprefix_attachment.

Risks

This operation can take a long time if you have a big number of attachments and/or a huge history on your objects.

  • ALTER TABLE execution time is roughly proportional to the table size

  • UPDATE TABLE execution time is mainly impacted by the number of rows and a bit by the table size.

Examples of execution time

Here are examples of the time it took with table size and count:

TableExecution
Size (GB)countSecondsQuery (beginning)
572500001486ALTER TABLE `attachment`
7,332000000212ALTER TABLE `priv_changeop_setatt`
7,3320000002621UPDATE `priv_changeop_setatt`,
2,41760000132ALTER TABLE `priv_changeop_setatt_scalar`
2,41760000465UPDATE `priv_changeop_setatt_scalar`,
3,11266700096ALTER TABLE `priv_changeop_links`
3,1126670001076UPDATE `priv_changeop_links`,
1,7753100069ALTER TABLE `priv_event_notification`
1,77531000613UPDATE `priv_event_notification`,
0,814300036ALTER TABLE `priv_changeop_setatt_longtext`
0,814300054UPDATE `priv_changeop_setatt_longtext`,

longqueriesmigration27.xlsx

 ALTER TABLE `priv_changeop_setatt` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttribute', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_setatt_scalar` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeScalar', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_setatt_longtext` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeLongText', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_changeop_links` ADD `optype` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'CMDBChangeOpSetAttributeLinks', ADD INDEX `optype` (`optype` (95))  
 ALTER TABLE `priv_event_notification` ADD `realclass` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT 'EventNotification', ADD INDEX `realclass` (`realclass` (95))  
 ALTER TABLE `attachment` ADD `creation_date` DATETIME, ADD `user_id` INT(11) DEFAULT 0, ADD INDEX `user_id` (`user_id`)  
 UPDATE `priv_changeop_setatt`,`priv_changeop` SET  `priv_changeop_setatt`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_setatt_scalar`,`priv_changeop` SET  `priv_changeop_setatt_scalar`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt_scalar`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_setatt_longtext`,`priv_changeop` SET  `priv_changeop_setatt_longtext`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_setatt_longtext`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_changeop_links`,`priv_changeop` SET  `priv_changeop_links`.`optype` = `priv_changeop`.`optype` WHERE `priv_changeop_links`.`id` = `priv_changeop`.`id`  
 UPDATE `priv_event_notification`,`priv_event` SET  `priv_event_notification`.`realclass` = `priv_event`.`realclass` WHERE `priv_event_notification`.`id` = `priv_event`.`id`

Mitigation

To identify tables which can take time, you can use this query, modified with your true itop db name

SELECT TABLE_NAME AS "Tables", 
    round(((data_length + index_length) / 1024 / 1024), 2) AS SIZE 
  FROM information_schema.tables 
  WHERE table_schema =  'itop db name'
  ORDER BY SIZE

Ensure that you have at least the size of the biggest table in free disk space on your iTop server

Then run the upgrade process on a test environment on a copy of your production database. The setup.log file will provide you the exact queries which run.

You can run those SQL queries on your production database before upgrading ! Apart from the performance degradation it can induce during the execution, there is no risk to break iTop as it will just ignore the added columns, until you upgrade it to version 2.7

If you run manually the ALTER TABLE on a given table, run also the UPDATE query, otherwise your database will be incoherent and iTop 2.7 will not work.
There is no UPDATE query for attachment table.

Setup process

If your browser returns a timeout during Setup database upgrade, don't kill your web server nor your database server. As despite this browser message, the Setup is going-on.

You can connect to mysql to check the queries which are on-going, you will see the time already spent on the current query, if you run the command again, the time will increase or show the next query.

php>mysql -u root -p xxxx
mysql> processlist;

As long as queries are ongoing, the setup is still going on. Then run

tail -f setup.
 
2020-03-02 13:49:52 | Ok      | <---- Exiting read only mode | SetupLog

to ensure that the setup is ended.

If your browser timeout, then the Setup is not completed. Once you have ensured that the database upgrade is finished, you must run the Setup again, also this time it will be faster as the database upgrade will not be performed again.

Second iTop Upgrade to 2.7

Important thing to know if you have rolled-back your 2.7 iTop upgrade,
and now want to upgrade again the same iTop to 2.7.0 or 2.7.1:

If you upgrade your production instance of iTop to 2.7 version, then later for whatever reason, you downgrade your iTop to any previous version. Everything will work smoothly, but the day you upgrade again to 2.7.0 or 2.7.1, we have a known issue in that case. To fix it you must run the Database integrity menu and fix manually in SQL directly on your MySQL or MariaDB database, the missing finalclass values for objects created in your iTop during the rollback interval.

Portal

Incompatible Extensions

Because of the Silex to Symphony migration, the following extensions are not compatible with iTop 2.7 Portal. A new version will be published mid of April 2020 and if you have deployed them on your iTop, you must upgrade those extensions before upgrating your iTop.

If you are a Combodo customer, using an iTop Professional or Essential:
This does not apply to you!

Custom extensions on Portal

If you have custom extensions bringing new bricks in your portal, you will need to get/write a new version of those extensions.

Because, in order to ensure better security, support and sustainability; we migrated the portal's framework from Silex 2.x to Symfony 3.4. Even though we managed to keep a backward compatibility for most of the code, if you made a custom extension for the portal, you are most likely to rework part of it.

Read this page to check if your extension is concerned.

End of Legacy Portal

As announced, the Legacy portal is no more available in iTop 2.7

XML Datamodel

Breaking changes

The XML default datamodel of iTop 2.7, contains a few changes which can collide with changes you may have done already on your iTop datamodel though extensions (or using the ITSM Designer if your are a Combodo customer).

Those conflicts should be handled automatically during iTop Setup, if not read carefully the message, it explains which XML node is failing.

Branding

  • The default theme is now included under /itop_design/branding/themes/theme[@id=“light-grey”], so if you altered the branding node, make sure to put the alteration flag (eg. _delta=“define”) on the subnodes.

itop_design iTop 2.7.0
 
  <branding>
    <themes>
      <theme id="light-grey">
        ...

No more working:

itop-design in MyExtension
 
  <branding _delta="define">
    <main_logo>
      <fileref ref="logo-combodo_f737e922334a6d51b0d98e9f590d2295"/>
    </main_logo>
    <login_logo>
      ...
  </branding>

Compatible with 2.7:

itop-design in MyExtension
 
  <branding>
    <main_logo _delta="define">
      <fileref ref="logo-combodo_f737e922334a6d51b0d98e9f590d2295"/>
    </main_logo>
    <login_logo _delta="define">
      ...
  </branding>

Legacy customers portal

The legacy customers portal was deprecated for a few releases and has now been completly removed. If you had redefined some of its constants or the routing to it, you need to correct your XML.

Constants: Remove all constant nodes starting with “PORTAL_” as they don't exist anymore.

itop_design iTop 2.6 and earlier
 
<constants>
    <constant id="PORTAL_POWER_USER_PROFILE">...</constant>
    <constant id="PORTAL_SERVICECATEGORY_QUERY">...</constant>
    ...
</constants>

Routing: Remove “legacy_portal” from the portal nodes.

itop_design iTop 2.6 and earlier
 
<portals>
    <portal id="legacy_portal">
        ...
    </portal>
</portals>

Customers portal

Navigation rules have been added under /itop_design/module_designs/module_design[@id=“itop-portal”]/forms/form[@id=“<FORM_ID>”]/properties for the “ticket-create”, “ticket-edit”, “ticket-reopen” and “ticket-apply-stimulus” forms, so if you altered the properties node, make sure to put the alteration flag (eg._delta=“define”) on the subnodes.

itop_design / module_designs / module_design / forms iTop 2.7.0
 
  <form id="ticket-create">
    <properties>
      <navigation_rules>
        <submit>
          <default>go-to-open-requests</default>
        </submit>
        ...

No more working:

itop-design / module_designs / module_design / forms in MyExtension
 
  <form id="ticket-create">
    <properties _delta="define">
      <always_show_submit>true</always_show_submit>
    </properties>
      ...
  </form>

Compatible with 2.7:

itop-design / module_designs / module_design / forms in MyExtension
 
  <form id="ticket-create">
    <properties>
      <always_show_submit _delta="define">true</always_show_submit>
    </properties>
      ...
  </form>

Admin Tools menus

The Admin tools sub-menus have been moved under the newly created group-menus Configuration and System. If you have redefine those menus, it may not work as expected.

Other

  • A new GetTicketRefFormat() method is now part of the Ticket|UserRequest|Incident|Problem|Change classes, so if you added a custom method with the same name, you'll have to adjust your code.

Deprecations

While these are not breaking changes, you should avoid using deprecated code. This is a summary of those introduced in the 2.7 version:

  • You should verify if you make use of the deprecated MetaModel::GetNextKey, such use is generally done into /itop_design/classes/class/methods/method[@id='DBInsertNoReload']

  • Portal: Action rules of type goto should be replaced by navigation rules. This means that instead of having an action rule in your brick, you should have a navigation rule in the corresponding form. Search for the following XPath:

    •  

    /itop_design/module_designs/module_design/action_rules/action_rule/submit

    •  

    /itop_design/module_designs/module_design/action_rules/action_rule/cancel

For developers

User rights applied on the User class

Previously PHP code getting User object instances were querying database regardless of the current user rights. This was changed in 2.7.0.

However, some code still needs to access the User class even if the current user doesn't have rights on this class. To do so, you will need to change your code to use the AllowAllData option.

Two examples of “no more working code” and the “appropriate fix”:

MetaModel::GetObject

// before 2.7.0 this was working for non admin users
$oUser = MetaModel::GetObject('User', $iCurrentUserId);
 
// After 2.7.0 to search for objects of the User class 
// You need to explicitly specify to ignore current user rights on the User class
// Forcing the 4st parameter to true, bypass "current user rights"
$oUser = MetaModel::GetObject('User', $iCurrentUserId, true, true); 

Reference: MetaModel::GetObject

DBSearch::AllowAllData

// before 2.7.0 this was working for non admin users
$oFilter = DBSearch::FromOQL('SELECT User WHERE id = :id');
$oSet = new DBObjectSet($oFilter, (), ('id' => $iCurrentUserId));
$oCurrentUser = $oSet->Fetch();
 
// After 2.7.0 you should add this to get Users objects
// Despite current user doesn't have rights on the User class :
$oFilter = DBSearch::FromOQL('SELECT User WHERE id = :id');
$oFilter->AllowAllData(); // this method call will bypass user access rights
$oSet = new DBObjectSet($oFilter, (), ('id' => $iCurrentUserId));
$oCurrentUser = $oSet->Fetch();

Reference: DBSearch::AllowAllData

ApplyStimulus changed

If the stimulus is not applicable to the object in its current state, the method ApplyStimulus() now returns false', instead of true'' before

Removed images

Many images have been replaced by Font Awesome icons in the admin. console. Those that were not used anymore have been removed from the iTop package (/images folder). This means that if you were using them in your extensions, you should change your code accordingly.

images/actions_bkg.png
images/actions_left.png
images/asc.gif
images/help.png
images/home.png
images/menu.png
images/mini-arrow-orange-open.gif
images/mini-arrow-orange.gif
images/mini_add.gif
images/mini_search.gif
images/mini_tree.gif
images/newsroom-message.svg
images/newsroom_menu.png
images/on-off-menu.png
images/onOffBtn.png
images/pencil-menu.png
images/printableversion.png
images/reload.png
images/searchBtn.png
images/settings.gif
images/zoom.gif
标签:
由 superadmin 在 2020/08/27, 15:57 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司