iTopCN – 自动化与工单管理

Docs: SPOC 与合作伙伴

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中为中介公司（合作伙伴）配置工单处理，使其能够代表最终客户在门户中创建和管理工单。更多详细内容请参考 iTop 官方文档。

前提条件

场景

假设您的公司是 IT 服务提供商，部分最终客户不直接与您联系，而是通过一家中介公司。该中介公司在您的 iTop 门户中代表最终客户进行操作。

中介公司代表客户报告特定服务的事件
中介公司可能为多个客户扮演该角色
最终客户也可以自行报告事件或请求
中介公司只能查看他们创建的工单，不能查看其客户的其他工单（可能包含敏感信息）

数据模型变更

中介的客户

需要为每个中介公司存储其服务的客户，以及为每个客户服务的具体服务。在本教程中，假设给定客户购买的特定服务最多外包给一个中介。

通过在 lnkCustomerContractToService 类上添加记录中介公司的外键来实现：

<class id="lnkCustomerContractToService">
 <fields>
 <field id="managed_by_id" xsi:type="AttributeExternalKey" _delta="define">
 <sql>managed_by_id</sql>
 <target_class>Organization</target_class>
 <filter/>
 <dependencies/>
 <is_null_allowed>true</is_null_allowed>
 <on_target_delete>DEL_MANUAL</on_target_delete>
 <allow_target_creation>false</allow_target_creation>
 </field>
 </fields>
</class>

工单的请求者

由于中介代表客户创建工单，需要修改 Ticket 类上 caller_id 的过滤器，使其可以是：

客户组织中的任何人
或客户组织中管理某服务的中介组织中的任何人

<class id="Ticket">
 <fields>
 <field id="caller_id" xsi:type="AttributeExternalKey" _delta="must_exist">
 <filter _delta="redefine"><![CDATA[
 SELECT Person WHERE org_id = :this->org_id
 UNION
 SELECT Person AS p
 JOIN Organization AS i ON p.org_id=i.id
 JOIN lnkCustomerContractToService AS lnk ON lnk.managed_by_id = i.id
 JOIN CustomerContract AS cc ON lnk.customercontract_id = cc.id
 WHERE cc.org_id = :this->org_id
 ]]></filter>
 </field>
 </fields>
</class>

建议的服务

可以限制数据模型中仅呈现基于客户和请求者的有效服务：

<class id="UserRequest">
 <fields>
 <field id="service_id" xsi:type="AttributeExternalKey" _delta="must_exist">
 <filter _delta="redefine"><![CDATA[
 SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 WHERE cc.org_id = :this->org_id AND s.status != 'obsolete'
 AND l1.managed_by_id = 0
 UNION
 SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 JOIN Organization AS i ON l1.managed_by_id = i.id
 JOIN Person AS p ON p.org_id = i.id
 WHERE cc.org_id = :this->org_id AND s.status != 'obsolete'
 AND p.id = :this->caller_id
 ]]></filter>
 <dependencies>
 <attribute id="org_id"/>
 <attribute id="caller_id" _delta="define"/>
 </dependencies>
 </field>
 </fields>
</class>

自定义用户门户

对于中介公司，需要使其能够在创建用户请求之前选择客户。通过为具有特定角色的门户用户创建新的 BrowseBrick 来实现。

普通最终用户仍使用 mosaic 视图
中介用户使用列表浏览模式查看其各种客户
然后中介用户在工单创建表单中选择服务和服务子目录

新用户角色

创建一个没有特定访问权限的新角色，命名为 Portal Multi Contract User：

<user_rights>
 <profiles>
 <profile id="912" _delta="define">
 <name>Portal Multi Contract User</name>
 <description>Users with this profile are allowed to create UserRequest on iTop Portal in the name of customers that they serve</description>
 <groups/>
 </profile>
 </profiles>
</user_rights>

新 BrowseBrick

新的 browseBrick 必须限制为 Portal Multi Contract User 角色：

<brick id="intermediate-customers" xsi:type="Combodo\iTop\Portal\Brick\ManageBrick" _delta="define">
 <active>true</active>
 <width>6</width>
 <rank><default>60</default></rank>
 <title><default>Brick:Portal:IntermediateCustomers:Title</default></title>
 <description>Brick:Portal:IntermediateCustomers:Title+</description>
 <visible>
 <home>false</home>
 <navigation_menu>false</navigation_menu>
 </visible>
 <decoration_class><default>far fa-handshake fc-3x</default></decoration_class>
 <oql><![CDATA[SELECT Organization]]></oql>
 <export><export_default_fields>true</export_default_fields></export>
 <fields>
 <field id="org_id_friendlyname"/>
 <field id="start_date"/>
 <field id="end_date"/>
 </fields>
 <grouping>
 <tabs>
 <groups>
 <group id="all">
 <rank>2</rank>
 <title>Brick:Portal:Licences:Tab:All</title>
 <condition><![CDATA[SELECT Organization]]></condition>
 </group>
 </groups>
 </tabs>
 </grouping>
 <security>
 <allowed_profiles><![CDATA[SELECT URP_Profiles WHERE name = 'Portal Multi Contract User']]></allowed_profiles>
 </security>
</brick>

移除旧 BrowseBrick 的访问权限

旧 BrowseBrick 必须拒绝新角色访问：

<brick id="services" xsi:type="Combodo\iTop\Portal\Brick\BrowseBrick" _delta="must_exist">
 <security _delta="define">
 <denied_profiles><![CDATA[SELECT URP_Profiles WHERE name = 'Portal Multi Contract User']]></denied_profiles>
 </security>
</brick>

重新设计范围

需要重新设计范围：

<classes>
 <class id="Organization" _delta="must_exist">
 <scopes>
 <scope id="intermediate" _delta="define">
 <oql_view><![CDATA[SELECT Organization AS O WHERE (O.managed_by_id = :current_contact->org_id) OR (O.id = :current_contact->org_id)]]></oql_view>
 <allowed_profiles>
 <allowed_profile id="Portal Multi Contract User"/>
 </allowed_profiles>
 </scope>
 </scopes>
 </class>
 <class id="Contact" _delta="must_exist">
 <scopes>
 <scope id="intermediate" _delta="define">
 <oql_view><![CDATA[SELECT Contact AS C JOIN Organization AS O ON C.org_id = O.id WHERE C.status='active' AND (O.managed_by_id = :current_contact->org_id) OR (O.id = :current_contact->org_id)]]></oql_view>
 <oql_edit><![CDATA[SELECT Contact AS C WHERE C.org_id = :current_contact->org_id]]></oql_edit>
 <allowed_profiles>
 <allowed_profile id="Portal Multi Contract User"/>
 </allowed_profiles>
 </scope>
 </scopes>
 </class>
 <class id="Service" _delta="must_exist">
 <scopes>
 <scope id="intermediate" _delta="define">
 <oql_view><![CDATA[SELECT Service]]></oql_view>
 <allowed_profiles>
 <allowed_profile id="Portal Multi Contract User"/>
 </allowed_profiles>
 </scope>
 </scopes>
 </class>
 <class id="ServiceSubcategory" _delta="must_exist">
 <scopes>
 <scope id="intermediate" _delta="define">
 <oql_view><![CDATA[SELECT ServiceSubcategory]]></oql_view>
 <allowed_profiles>
 <allowed_profile id="Portal Multi Contract User"/>
 </allowed_profiles>
 </scope>
 </scopes>
 </class>
 <class id="UserRequest" _delta="must_exist">
 <scopes>
 <scope id="portal-partner-user" _delta="define">
 <oql_view><![CDATA[SELECT UserRequest AS T JOIN Organization AS O ON T.org_id = O.id WHERE (O.managed_by_id = :current_contact->org_id) OR (O.id=:current_contact->org_id)]]></oql_view>
 <oql_edit><![CDATA[SELECT UserRequest AS T]]></oql_edit>
 <allowed_profiles>
 <allowed_profile id="Portal Multi Contract User"/>
 </allowed_profiles>
 </scope>
 <scope id="in-contact" _delta="define">
 <oql_view><![CDATA[SELECT UserRequest AS T
 JOIN lnkContactToTicket AS l ON l.ticket_id = T.id
 WHERE l.contact_id = :current_contact_id ]]></oql_view>
 <oql_edit><![CDATA[SELECT UserRequest AS T]]></oql_edit>
 </scope>
 <scope id="mine" _delta="define">
 <oql_view><![CDATA[SELECT UserRequest AS T
 WHERE T.agent_id = :current_contact_id OR T.caller_id = :current_contact_id]]></oql_view>
 <oql_edit><![CDATA[SELECT UserRequest]]></oql_edit>
 </scope>
 </scopes>
 </class>
</classes>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:spoc

版本：3_2_0/customization/spoc.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 按服务子目录的 SLA

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中修改 SLA 逻辑，使 SLA 按服务子目录定义而非按客户定义。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

了解 TTO（响应时间）和 TTR（解决时间）截止时间如何为特定工单计算
了解如何更改计算逻辑

标准数据模型中的工作原理

数据模型

服务管理模块（服务、SLA、合同）

计算流程

1. 计算 TTO 和 TTR

当创建或修改用户请求或事件时，iTop 检索所有关联的计时器（默认 Time-To-Own 和 Time-To-Resolve），对每个计时器：

启动或停止计时器
计算与每个计时器关联的截止时间（如果有）
更新计时器子项值

1.2 计算截止时间

如何知道特定 TTO 或 TTR 目标何时达到？

TTO 和 TTR 使用相同的查询检索适用 SLT，使用 metric 参数（TTO 或 TTR），因为 SLT 标记为 TTO 或 TTR
它们还可以依赖 CoverageWindow 和 Holidays，使用 SLAs based on working hours 扩展

1.2.1 检索适用 SLT

SLT 告诉 iTop 对当前用户请求或事件应用什么延迟（TTO 或 TTR）。

SLT 检索查询定义为常量：

<constants>
 <constant id="RESPONSE_TICKET_SLT_QUERY" xsi:type="string" _delta="redefine"><![CDATA[
 SELECT SLT AS slt
 JOIN lnkSLAToSLT AS l1 ON l1.slt_id=slt.id
 JOIN SLA AS sla ON l1.sla_id=sla.id
 JOIN lnkCustomerContractToService AS l2 ON l2.sla_id=sla.id
 JOIN CustomerContract AS sc ON l2.customercontract_id=sc.id
 WHERE slt.metric = :metric
 AND l2.service_id = :this->service_id
 AND sc.org_id = :this->org_id
 AND slt.request_type = :request_type
 AND slt.priority = :this->priority
 ]]></constant>
</constants>

$sType=get_class($oTicket);
if ($sType == 'Incident')
 $sRequestType = 'incident';
else
 $sRequestType = $oTicket->Get('request_type');

修改方案

本教程描述一个特定的自定义数据模型，其中"SLA 按服务子目录定义"，但相同的逻辑适用于不同的数据模型。

标准数据模型中的结构

不同 SLA 可以应用于每个交付给客户的服务：服务 A 一个 SLA，服务 B 另一个 SLA
不同客户可以对同一服务应用不同的 SLA：服务 A 对客户 1 一个 SLA，对客户 2 另一个 SLA
SLA 由 SLT 组成
SLT 可以被多个 SLA 复用

修改步骤

1. 从 lnkCustomerContractToService 中移除 SLA

通过 XML 注入从 SLA 类中移除 customercontracts_list（不要通过标准 Designer UI 操作，否则会删除链接类）
注释或删除 SLA::CheckToWrite() 方法

<class id="SLA" _created_in="itop-service-mgmt" _delta="must_exist">
 <fields>
 <field id="customercontracts_list" xsi:type="AttributeLinkedSetIndirect" _delta="delete"/>
 </fields>
 <methods>
 <method id="DoCheckToWrite" _delta="delete"/>
 </methods>
 <presentation>
 <details _delta="redefine">
 <items>
 <item id="col:col0">
 <items>
 <item id="name"><rank>10</rank></item>
 <item id="org_id"><rank>20</rank></item>
 <item id="description"><rank>30</rank></item>
 </items>
 <rank>10</rank>
 </item>
 <item id="slts_list"><rank>20</rank></item>
 </items>
 </details>
 </presentation>
</class>

2. 在 ServiceSubcategory 上添加 SLA

<class id="ServiceSubcategory" _delta="if_exists">
 <fields>
 <field id="sla_id" xsi:type="AttributeExternalKey" _delta="define">
 <sql>sla_id</sql>
 <target_class>SLA</target_class>
 <on_target_delete>DEL_MANUAL</on_target_delete>
 <is_null_allowed>true</is_null_allowed>
 </field>
 </fields>
</class>

3. 强制提供服务子目录

如果希望在工单创建时设置截止时间，则必须提供服务子目录。标准数据模型中它不是必填的，需要修改使其必填。

适用 SLT

常量 RESPONSE_TICKET_SLT_QUERY 的值必须被覆盖：

SELECT SLT AS slt
JOIN lnkSLAToSLT AS l1 ON l1.slt_id=slt.id
JOIN SLA AS sla ON l1.sla_id=sla.id
JOIN ServiceSubcategory AS ss ON ss.sla_id=sla.id
WHERE slt.metric = :metric
AND ss.id = :this->servicesubcategory_id
AND slt.request_type = :request_type
AND slt.priority = :this->priority

扩展：SLA considering business hours

如果安装了此扩展并修改了 CoverageWindow 的定义位置（lnkCustomerContractToService 类中的 ExternalKey），则需要相应修改配置文件中 coverage_oql 参数。

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:sla-service-subcategory

版本：3_2_0/customization/sla-service-subcategory.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 按国家的假期 SLA

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中按国家使用不同的假期日历进行 SLA 计算。更多详细内容请参考 iTop 官方文档。

前提条件

目标

在 Coverage Windows 中添加指向 Holidays Calendar 的链接
修改 SLA 计算以考虑假期

在 Coverage Windows 中添加假期日历链接

在 CoverageWindow 类上添加 holidaycalendar_id 字段：

<classes>
 <class id="CoverageWindow" _created_in="combodo-sla-computation" _delta="must_exist">
 <fields>
 <field id="holidaycalendar_id" xsi:type="AttributeExternalKey" _delta="define">
 <sql>holidaycalendar_id</sql>
 <filter>SELECT HolidayCalendar</filter>
 <dependencies/>
 <is_null_allowed>true</is_null_allowed>
 <target_class>HolidayCalendar</target_class>
 <on_target_delete>DEL_MANUAL</on_target_delete>
 </field>
 <field id="holidaycalendar_name" xsi:type="AttributeExternalField" _delta="define">
 <extkey_attcode>holidaycalendar_id</extkey_attcode>
 <target_attcode>name</target_attcode>
 </field>
 </fields>
 <presentation>
 <details _delta="redefine">
 <items>
 <item id="name">
 <rank>10</rank>
 </item>
 <item id="description">
 <rank>20</rank>
 </item>
 <item id="holidaycalendar_id">
 <rank>30</rank>
 </item>
 </items>
 </details>
 </presentation>
 </class>
</classes>
<dictionaries>
 <dictionary id="EN US" _delta="must_exist">
 <entries>
 <entry id="Class:CoverageWindow/Attribute:holidaycalendar_id" _delta="define"><![CDATA[Holiday calendar ]]></entry>
 <entry id="Class:CoverageWindow/Attribute:holidaycalendar_id+" _delta="define"><![CDATA[]]></entry>
 <entry id="Class:CoverageWindow/Attribute:holidaycalendar_name" _delta="define"><![CDATA[Holiday calendar name]]></entry>
 <entry id="Class:CoverageWindow/Attribute:holidaycalendar_name+" _delta="define"><![CDATA[]]></entry>
 </entries>
 </dictionary>
</dictionaries>

修改 SLA 计算以考虑假期

在 iTop 实例的配置文件中调整 holidays_oql 参数：

'combodo-sla-computation' => array (
 'coverage_oql' =>
 'SELECT CoverageWindow AS cw
 JOIN lnkCustomerContractToService AS l1 ON l1.coveragewindow_id = cw.id
 JOIN CustomerContract AS cc ON l1.customercontract_id = cc.id
 WHERE cc.org_id= :this->org_id AND l1.service_id = :this->service_id',
 'holidays_oql' =>
 'SELECT Holiday AS h
 JOIN HolidayCalendar AS hc ON h.calendar_id=hc.id
 JOIN CoverageWindow AS cw ON cw.holidaycalendar_id=hc.id
 JOIN lnkCustomerContractToService AS l1 ON l1.coveragewindow_id=cw.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 WHERE cc.org_id = :this->org_id AND l1.service_id = :this->service_id',
),

创建假期日历并关联到覆盖窗口

创建假期和假期日历，将其关联到覆盖窗口，并调整客户合同。

可以按国家、团队、客户等定义不同的日历。

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:multiple-holiday-calendar

版本：3_2_0/customization/multiple-holiday-calendar.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 持久化统计 n:n

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中持久化存储 n:n 关系的计数，例如在团队上统计成员数量。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

在对象 A 的详情中显示通过多对多关系链接到对象 A 的对象 B 的数量。本示例使用 Team 与 Person 的关系，在 Team 上存储团队成员数量。

lnkPersonToTeam 类有 person_id 和 team_id 外键，存储多对多关系
Team 上有 persons_list 字段，提供链接到该团队的人员列表
Person 上有 teams_list 字段，提供链接到该人员的团队列表
需要在 Team 类上创建 persons_count 字段，存储团队中的人员数量

需要支持：

在 A 对象列表中查看此计数
通过 OQL 查询轻松查找具有超过 10 个相关 B 对象的 A 对象

iTop 3.1.1+ 方式

使用事件机制，订阅特定事件并在事件触发时执行方法。

计算成员

public function CountMembers(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $oLnkSet = $this->Get('persons_list');
 if (is_object($oLnkSet)) {
 $this->Set('persons_count', $oLnkSet->Count());
 $this->DBUpdate();
 }
}

处理字段

<class id="Team" _delta="must_exist">
 <fields>
 <field id="persons_list" _delta="must_exist">
 <with_php_computation>true</with_php_computation>
 </field>
 <field id="persons_count" xsi:type="AttributeInteger" _delta="define">
 <sql>persons_count</sql>
 <default_value>0</default_value>
 <is_null_allowed>false</is_null_allowed>
 </field>
 </fields>
</class>

订阅事件

<class id="Team" _delta="must_exist">
 <event_listeners>
 <event_listener id="CountMembers" _delta="define">
 <event>EVENT_DB_LINKS_CHANGED</event>
 <callback>CountMembers</callback>
 <rank>0</rank>
 </event_listener>
 </event_listeners>
</class>

3.1.1 之前的方式

这种方式更复杂。需要确定何时计算什么。

在 Team 上

添加计数器字段：

<class id="Team" _delta="must_exist">
 <fields>
 <field id="persons_count" xsi:type="AttributeInteger" _delta="define">
 <sql>persons_count</sql>
 <default_value>0</default_value>
 <is_null_allowed>false</is_null_allowed>
 </field>
 </fields>
</class>

创建函数：

public function ComputeValues()
{
 $this->ComputePersons();
}

public function ComputePersons($iDelta=0)
{
 if ($iDelta==0)
 {
 $oSet = $this->Get('persons_list');
 $i = $oSet->count();
 }
 else
 {
 $i = $this->Get('persons_count') + $iDelta;
 }
 $this->Set('persons_count', $i);
 return $i;
}

在链接对象上

创建

要求 Team 重新计算其计数

修改

需要考虑所有可能的变更：

团队变更：旧团队减一，新团队加一

删除

要求 Team 从其计数中减一

public function UpdateRemote($iTeamId, $iDelta = 0)
{
 $oTeam = MetaModel::GetObject('Team', $aChanges['Team'], false, true);
 if (is_object($oTeam ))
 {
 $oTeam->ComputePersons($iDelta);
 $oTeam->DBUpdate();
 }
}

protected function AfterInsert()
{
 $this->UpdateRemote($this->Get('team_id'), 1);
}

protected function AfterUpdate()
{
 $aChanges = $this->ListPreviousValuesForUpdatedAttributes();

 if (array_key_exists('team_id', $aChanges))
 {
 $this->UpdateRemote($aChanges['team_id'], -1);
 $this->UpdateRemote($this->Get('team_id'), 1);
 }
}

protected function AfterDelete()
{
 $this->UpdateRemote($this->Get('team_id'), -1);
}

在 Person 上

人员创建 → 通过关联链接的创建处理
人员删除 → 通过关联链接的级联删除处理

无需额外操作！

通用 UpdateCounter 函数

/**
 * @param $id 远程对象的 ID
 * @param $sClass 远程对象的类名
 * @param $sCounterCode 远程类上存储关系计数的属性代码
 * @param $iDelta 添加到计数器的数值（可为负数）
 */
public function UpdateCounter($id, $sClass, $sCounterCode, $iDelta=0)
{
 if (in_array($sCounterCode,MetaModel::GetAttributesList($sClass)))
 {
 $oObject = MetaModel::GetObject($sClass, $id, false, true);
 if (is_object($oObject ) && ($iDelta!=0))
 {
 $i = $oObject->Get($sCounterCode) + $iDelta;
 $oObject->Set($sCounterCode, $i);
 $oObject->DBUpdate();
 }
 }
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:count-linkset-indirect

版本：3_2_0/customization/count-linkset-indirect.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 从父对象继承服务

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现子组织从父组织继承服务的功能。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

使子组织能够继承父组织的服务。需要修改：

Console 中用户请求编辑时建议的服务列表
检索用于计算 TTO 和 TTR 截止时间的适用 SLT 的方式
检索用于计算 TTO 和 TTR 截止时间的适用 Coverage Window 的方式
Portal 中允许的服务和服务子目录列表

数据模型

修改 UserRequest 和/或 Incident 类的 service_id 字段的 filter：

<field id="service_id" xsi:type="AttributeExternalKey">
 <filter _delta="redefine">
 <![CDATA[
 SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 JOIN Organization AS root ON cc.org_id = root.id
 JOIN Organization AS child ON child.parent_id BELOW root.id
 WHERE child.id = :this->org_id AND s.status != 'obsolete'
 ]]>
 </filter>
</field>

适用 SLT

修改检索适用 SLT 的查询：

<constants>
 <constant id="RESPONSE_TICKET_SLT_QUERY" xsi:type="string" _delta="redefine"><![CDATA[
 SELECT SLT AS slt
 JOIN lnkSLAToSLT AS l1 ON l1.slt_id=slt.id
 JOIN SLA AS sla ON l1.sla_id=sla.id
 JOIN lnkCustomerContractToService AS l2 ON l2.sla_id=sla.id
 JOIN CustomerContract AS sc ON l2.customercontract_id=sc.id
 JOIN Organization AS root ON sc.org_id = root.id
 JOIN Organization AS child ON child.parent_id BELOW root.id
 WHERE slt.metric = :metric AND l2.service_id = :this->service_id
 AND child.id = :this->org_id AND slt.request_type = :request_type
 AND slt.priority = :this->priority
 ]]></constant>
</constants>

检索到的 SLT 用于计算拥有或解决特定工单的截止时间，以保持在 SLA 范围内。更多详情参见按服务子目录的 SLA 教程。

适用 Coverage Window

需要在配置文件中修改模块 combodo-sla-computation 的 coverage_oql 参数。该参数是一个 OQL 查询，检索当前工单的适用 CoverageWindow。

替换为以下查询：

SELECT CoverageWindow AS cw
JOIN lnkCustomerContractToService AS l1 ON l1.coveragewindow_id = cw.id
JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
JOIN Organization AS root ON cc.org_id=root.id
JOIN Organization AS child ON child.parent_id BELOW root.id
WHERE child.id= :this->org_id
AND l1.service_id = :this->service_id

逻辑：

获取任何组织的客户合同
该组织在组织树中位于工单组织之下
工单组织是组织树中的子组织

增强门户

默认门户中定义的服务和服务子目录范围限制了可见性，需要修改这些范围，使门户用户能够查看（和选择）其用户组织或任何上级组织购买的服务。

<module_design id="itop-portal">
 <classes>
 <class id="ServiceFamily">
 <scopes>
 <scope id="all">
 <oql_view _delta="redefine"><![CDATA[SELECT ServiceFamily AS sf
 JOIN Service AS s ON s.servicefamily_id = sf.id
 JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 JOIN Organization AS root ON cc.org_id = root.id
 JOIN Organization AS child ON child.parent_id BELOW root.id
 WHERE child.id = :current_contact->org_id AND s.status != 'obsolete']]></oql_view>
 </scope>
 </scopes>
 </class>
 <class id="Service">
 <scopes>
 <scope id="all">
 <oql_view _delta="redefine"><![CDATA[SELECT Service AS s
 JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 JOIN Organization AS root ON cc.org_id = root.id
 JOIN Organization AS child ON child.parent_id BELOW root.id
 WHERE child.id = :current_contact->org_id AND s.status != 'obsolete']]></oql_view>
 </scope>
 </scopes>
 </class>
 <class id="ServiceSubcategory">
 <scopes>
 <scope id="all">
 <oql_view _delta="redefine"><![CDATA[SELECT ServiceSubcategory AS ss
 JOIN Service AS s ON ss.service_id=s.id
 JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
 JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
 JOIN Organization AS root ON cc.org_id = root.id
 JOIN Organization AS child ON child.parent_id BELOW root.id
 WHERE child.id = :current_contact->org_id AND s.status != 'obsolete']]></oql_view>
 </scope>
 </scopes>
 </class>
 </classes>
</module_design>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:service-heritage

版本：3_2_0/customization/service-heritage.txt · Last modified: 2024/12/04 11:58 by 127.0.0.1

Docs: 存储 1:n 关系计数

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中持久化存储 1:n 关系的计数，例如在工单上统计关联的工作订单数量。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

在对象 A 的详情中显示通过一对多关系（类 B 上的外键指向 A）链接到对象 A 的对象 B 的数量。

将介绍两种场景：

在 Ticket 上统计关联的 WorkOrders
在 User Request 上统计子请求数量（特殊情况：类 A 和类 B 是同一个类）

这些信息在单个工单/用户请求的详情中很容易查看，但无法快速检索所有具有超过 2 个工作订单/子请求的工单，或没有工作订单/子请求的工单。本教程解释如何解决此问题。

工单上的工作订单

需要：

在 Ticket 类上创建 count_workorders_list 字段，永久存储数量以便查询
Ticket 上有 workorders_list 字段，提供当前工单下的子请求列表
WorkOrder 上有 ticket_id 字段，提供需要更新工作订单计数的工单

确定何时重新计算：

工作订单单独创建、修改或删除时
工作订单列表与工单本身同时修改时

<fields>
 <field id="workorders_list" xsi:type="AttributeLinkedSet">
 <with_php_computation _delta="force">true</with_php_computation>
 </field>
 <field id="count_workorders" xsi:type="AttributeInteger" _delta="define">
 <sql>count_workorders</sql>
 <default_value>0</default_value>
 <is_null_allowed>false</is_null_allowed>
 <tracking_level>all</tracking_level>
 </field>
<fields>
<event_listeners>
 <event_listener id="EvtOnLinksChanged" _delta="define">
 <event>EVENT_DB_LINKS_CHANGED</event>
 <callback>OnLinksChanged</callback>
 <rank>0</rank>
 </event_listener>
 <event_listener id="EvtBeforeWrite" _delta="define">
 <event>EVENT_DB_BEFORE_WRITE</event>
 <callback>BeforeWrite</callback>
 <rank>0</rank>
 </event_listener>
</event_listeners>
<methods>

public function OnLinksChanged(?Combodo\iTop\Service\Events\EventData $oEventData)
{ // 注意方法声明中的 ?，允许使用 null 作为参数
 $oSet = $this->Get('workorders_list');
 $this->Set('count_workorders', $oSet->count());
 // $this->DBUpdate(); 当 $this 被修改时无用，因为回调结束时自动调用
}
public function BeforeWrite(?Combodo\iTop\Service\Events\EventData $oEventData)
{
 $aChanges = $this->ListChanges();
 if (array_key_exists('workorders_list', $aChanges)) {
 $this->OnLinksChanged(null); // 没有 EventData 可提供，但此方法中未使用
 }
}

当 WorkOrder 对象单独创建、删除或修改（而非在其工单修改的上下文中）时，回调 Ticket::OnLinksChanged() 将自动调用。

子用户请求

此用例与上述非常相似。由于类 A 和 B 相同，之前的方法有所不同，现在已不再是问题。

需要：

在 UserRequest 类上创建 count_related_request_list 字段，永久存储子请求数量以便查询
UserRequest 上有 related_request_list 字段，提供当前请求下的子请求列表
UserRequest 上有 parent_request_id 字段，提供父请求

<fields>
 <field id="related_request_list" xsi:type="AttributeLinkedSet">
 <with_php_computation _delta="force">true</with_php_computation>
 </field>
 <field id="count_related_request" xsi:type="AttributeInteger" _delta="define">
 <sql>count_related_request</sql>
 <default_value>0</default_value>
 <is_null_allowed>false</is_null_allowed>
 <tracking_level>all</tracking_level>
 </field>
<fields>
<event_listeners>
 <event_listener id="EvtOnLinksChanged" _delta="define">
 <event>EVENT_DB_LINKS_CHANGED</event>
 <callback>OnLinksChanged</callback>
 <rank>0</rank>
 </event_listener>
 <event_listener id="EvtBeforeWrite" _delta="define">
 <event>EVENT_DB_BEFORE_WRITE</event>
 <callback>BeforeWrite</callback>
 <rank>0</rank>
 </event_listener>
</event_listeners>
<methods>

public function BeforeWrite(?Combodo\iTop\Service\Events\EventData $oEventData)
{
 $aChanges = $this->ListChanges();
 if (array_key_exists('related_request_list', $aChanges)) {
 $this->OnLinksChanged(null);
 // 切勿在回调中调用 $this->DBUpdate();，无用且被忽略
 }
}
public function OnLinksChanged(?Combodo\iTop\Service\Events\EventData $oEventData)
{
 $oSet = $this->Get('related_request_list');
 $this->Set('count_related_request', $oSet->count());
 // 仅在更新的对象不是 $oEventData->Get('object') 时调用 ->DBUpdate() 才有用
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:count-linkset

2025/05/19 18:31 by127.0.0.1

版本：3_2_0/customization/count-linkset.txt · Last modified: 2025/05/19 18:31 by 127.0.0.1

Docs: 对 n:n 远程字段求和

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现 n:n 关系的计算字段，例如在合同上统计所有关联组件的成本总和。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

在对象 A 的详情中显示通过多对多关系链接到对象 A 的对象 B 的总和。本示例在 Contract 上统计每个包含的 Component 的成本总和。

cost 是 Component 类的字段（标准数据模型中不存在此类）
在 Contract 类上创建 components_total_cost 字段，存储 Component 成本的总和
lnkContractToComponent 类有 contract_id 和 component_id 外键，存储多对多关系
Component 上有 contracts_list 字段，提供链接到该组件的合同列表
Contract 上有 components_list 字段，提供链接到该合同的组件列表

需要支持：

能够搜索该"计算"字段
能够对该"计算"字段运行审计

n:n 聚合策略

实现此类"计算"字段（使用多对多关系末端对象的聚合函数）的通用策略：

为了能够查询，必须将其存储在数据库中，因此设为持久字段
为确保始终准确，需要识别何时必须重新计算并执行

在类 A 上

编写方法计算"计算"字段的值。最好实现"增量"计算方法，接受远程对象修改导致的增减值作为参数
在 EVENT_DB_SET_INITIAL_ATTRIBUTE_FLAGS 上的回调方法：指定"计算"字段在创建表单中隐藏
在 EVENT_DB_SET_ATTRIBUTE_FLAGS 上的回调方法：指定"计算"字段在修改时只读

在链接类上

有两种选择：

简单策略：使用 EVENT_DB_LINKS_CHANGED 和 ComputeComponents 作为回调（与 1:n 策略相同）
复杂策略（本教程采用）：避免完整重新计算。适用于 LinkedSet 中对象数量庞大、希望避免完整重新计算的场景
- EVENT_DB_AFTER_WRITE 上的回调方法：强制重新计算所有受影响的对象 A
- EVENT_DB_AFTER_DELETE 上的回调方法：强制重新计算对象 A

在依赖类 B 上

EVENT_DB_AFTER_WRITE 上的回调方法：如果用于计算的字段发生变化（此处为 Component.cost），更新对象 A

提示与说明

使用 EVENT_DB_AFTER_WRITE 级联变更，而不是 EVENT_DB_BEFORE_WRITE，因为否则远程对象尚未保存到数据库，后续的 CHECK_TO_WRITE 可能失败并阻止写入

在 Contract 上

首先创建两个函数：

一个从头重新计算扩展总成本，逐个解析扩展
一个通过仅添加或移除一个组件来计算总和（提高效率）

// 此函数检索所有相关组件并求和其成本
public function ComputeComponents()
{
 $iSum = 0;
 $oSet = $this->Get('components_list');
 while($oLnk = $oSet->Fetch()) {
 $oComponent = MetaModel::GetObject('Component', $oLnk->Get('component_id'), false, true);
 if (is_object($oComponent )) {
 $iSum = $iSum + $oComponent ->Get('cost');
 }
 }
 $this->Set('components_total_cost', $iSum);
}

public function ComputeComponentsDirect($iDelta)
{
 // 防止数据库不一致
 if (is_numeric($iDelta)) {
 $iNewTotal = $this->Get('components_total_cost') + $iDelta;
 $this->Set('components_total_cost', $i);
 }
}

在链接对象上

链接对象创建、删除或修改时的处理：

创建

要求 Contract 将该组件成本添加到其总和中

修改

需要考虑所有可能的变更：

合同变更但组件不变：从旧合同移除组件成本，向新合同添加组件成本
组件变更但合同不变：从合同移除旧组件成本，向合同添加新组件成本
两者同时变更：从旧合同移除旧组件成本，向新合同添加新组件成本

删除

要求 Contract 从总和中移除被删除的组件成本

public function AfterWrite(Combodo\iTop\Service\Events\EventData $oEventData)
{
 if ($oEventData->Get('is_new')) {
 $this->OnAddRemoveOfALink($this->Get('contract_id'), $this->Get('component_id'), true);
 } else {
 $aChanges = $this->ListPreviousValuesForUpdatedAttributes();
 $bContractChanged = array_key_exists('contract_id', $aChanges);
 $bComponentChanged = array_key_exists('component_id', $aChanges);

 if ($bContractChanged || $bComponentChanged) {
 $iRemovedComponent = ($bComponentChanged) ? $aChanges['component_id'] : $this->Get('component_id');
 $iAddedComponent = $this->Get('component_id');
 $iPreviousContract = ($bContractChanged) ? $aChanges['contract_id'] : 0;
 $iNewContract = $this->Get('contract_id');

 $this->OnAddRemoveOfALink($iPreviousContract, $iRemovedComponent, false);
 $this->OnAddRemoveOfALink($iNewContract , $iAddedComponent , true);
 }
 }
}
public function AfterDelete(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $this->OnAddRemoveOfALink(($this->Get('contract_id'), $this->Get('component_id'), false);
}

public function OnAddRemoveOfALink($idContract, $idComponent, $bAdd)
{
 $oComponent = MetaModel::GetObject('Component', $idComponent, false, true);
 $oContract = MetaModel::GetObject('Contract', $idContract, false, true);

 if (is_object($oComponent) && is_object($oContract )) {
 $iCost = $oComponent ->Get('cost');
 $iDelta = ($bAdd) ? $iCost : - $iCost ;
 $oContract->ComputeComponentsDirect($iDelta);
 $oContract->DBUpdate();
 }
}

在 Component 上

需要处理组件的各种变更场景：

组件创建 → 通过关联链接的创建处理
组件删除 → 通过关联链接的级联删除处理
组件 cost 修改 → 需要处理

public function AfterWrite(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $aChanges = $this->ListPreviousValuesForUpdatedAttributes();
 if (array_key_exists('cost', $aChanges))
 {
 $iDelta = $this->Get('cost') - $aChanges['cost];
 $oSet = $this->Get('contracts_list');
 while($oLnk = $oSet->Fetch())
 {
 $oContract = MetaModel::GetObject('Contract', $oLnk->Get('contract_id'), false, true);
 $oContract->ComputeComponentsDirect($iDelta)
 $oContract->DBUpdate();
 }
 }
}

陷阱

理论上以上代码已足够，但存在一个问题：

当在同一事务中更新 Contract 和 lnkContractToComponent 时，代码会启动 Contract::DBUpdate()，其中为每个 lnkContractToComponent 调用 OnInsert()、OnUpdate() 或 OnDelete()，这些代码会执行 $oContract->DBUpdate()，从而进入无限循环（代码会阻止此循环）。结果是第二个 $oContract->DBUpdate() 完全不会执行（静默失败）。

解决方案：在 Contract 本身上编写特殊处理：

创建时，链接可能同时创建（例如通过 Object-Copier）
更新时，从头重新计算总和，因为已知链接处理期间的 Contract DBUpdate 请求会被重入保护忽略
删除时，无需操作

public function BeforeWrite(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $aChanges = $this->ListChanges();
 if (array_key_exists('components_list', $aChanges))
 {
 $this->ComputeComponents();
 }
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:cascade-update2

2025/05/21 11:01 by127.0.0.1

版本：3_2_0/customization/cascade-update2.txt · Last modified: 2025/05/21 11:01 by 127.0.0.1

Docs: 复制 n:n 对象

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中使用对象复制器扩展复制 n:n 关系，例如从 FunctionalCI 创建工单时自动复制关联的联系人。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

丰富 User actions configurator 扩展，以复制关系。

示例：从 FunctionalCI 创建工单时，检索链接到该 FunctionalCI 的联系人，并自动将其链接到工单。

public function CopyContactsFromFunctionalCI($oSource)
{
 // 此方法应从 FunctionalCI 调用
 $sSourceClass = get_class($oSource);
 if ($sSourceClass != 'FunctionalCI')
 {
 throw new Exception("Wrong source class '$sSourceClass' :
 CopyContactsFromFunctionalCI method should be called by a user action on a FunctionalCI!");
 }
 // 此方法被调用两次：
 // 创建表单显示时：'????'
 // 保存时：'apply_new'
 // 仅在一个情况下复制链接，避免链接重复
 $sOperation= utils::ReadPostedParam('operation');
 if ($sOperation == 'apply_new')
 {
 return;
 }
 // 获取相关对象列表
 $oSetSrc = new CMDBObjectSet(DBObjectSearch::FromOQL("
 SELECT Contact AS c
 JOIN lnkContactToFunctionalCI AS l1 ON l1.contact_id = c.id
 WHERE l.functionalci_id = :id"), array(), array('id'=>$oSource->GetKey()));
 // 更简单的方案：$oSetSrc = $oSource->Get('contacts_list');

 $oSetDst = $this->Get('contacts_list');
 while ($oSrc = $oSetSrc->Fetch())
 {
 $oLnkDst = MetaModel::NewObject('lnkContactToTicket');
 $oLnkDst->Set('contact_id', $oSrc->GetKey());
 $oSetDst->AddItem($oLnkDst);
 }
 $this->Set('contacts_list', $oSetDst);
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:object-copier-linkedset

版本：3_2_0/customization/object-copier-linkedset.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 获取解决延迟

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中获取考虑覆盖窗口（Coverage Window）的解决延迟，即统计工单在 TTR 中实际花费的工作时间（排除非工作时段）。更多详细内容请参考 iTop 官方文档。

前提条件

计时器内部子项

计时器（Stopwatch）包含 4 个内部子项：

代码	标签	含义
`timespent`	Elapsed	在关联状态中花费的总时间（计时器运行时此值不准确）
`started`	Started	计时器首次启动的时间
`laststart`	LastStart	计时器最后一次启动的时间（停止时为空）
`stopped`	Stopped	计时器最后一次停止的时间（运行时为空）

需求分析

Resolution delay 提供的是 ttr_started 和 ttr_stopped 之间的时间差，但这可能不是您想要的——它包含所有时间段（包括非工作时间）。

您需要的是支持团队实际花费在解决工单上的时间，排除覆盖窗口之外的时段。这正是计时器子项 timespent 所存储的值。

iTop Essential & Professional

在 ITSM Designer 中：

进入 UserRequest 类，点击新建字段图标
在弹出窗口中选择：
- 类型 = Stopwatch Value
- 计时器 = 选择 ttr
- 值 = Total time spent
将该字段添加到展示/详情视图中

iTop Community

创建 iTop 扩展，在 XML 中声明 UserRequest 类的字段：

<fields>
 <field id="ttr_timespent" xsi:type="AttributeSubItem" _delta="define">
 <target_attcode>ttr</target_attcode>
 <item_code>timespent</item_code>
 </field>
</fields>

无论是否在详情屏幕中显示，该字段都可在"自定义此列表"视图、Dashlet 和 OQL 查询中使用。

示例对比

计时器多次启动和停止，因此 “Elapsed” 不等于 “Started” 与 “Stopped” 的差值
7×60s + 49s = 469s：Provider time spent 只是 “Elapsed” 子项的友好显示

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-subitems

2024/09/10 10:25 by127.0.0.1

版本：3_2_0/customization/add-subitems.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 级联变更关闭

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现当变更关闭时，自动关闭所有关联的用户请求。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

当变更关闭时，自动关闭所有关联的用户请求。

限制：提供的 XML 示例仅适用于 itop-change-mgmt 选项，不适用于 itop-change-mgmt-ITIL。

需要完成：

添加方法，对每个关联请求执行 ev_autoresolve 刺激
在变更关闭时使用此方法作为动作

计算方法

修改 Change 类，添加以下 PHP 方法：

/**
 * @return bool 成功返回 true，返回 false 阻止转换发生
 */
public function ResolveRelatedRequest()
{
 $sOQL = "SELECT UserRequest WHERE parent_change_id = :ticket AND status != 'resolved'";
 $oRelatedRequestSet = new DBObjectSet(DBObjectSearch::FromOQL($sOQL), array(), array('ticket' => $this->GetKey()));
 while($oRequest = $oRelatedRequestSet->Fetch())
 {
 if ($oRequest->Get('status') != 'resolved' && $oRequest->Get('status') != 'closed' )
 {
 $oRequest->Set('solution', 'ticket automatically resolved by '.$this->Get('friendlyname'));
 $oRequest->ApplyStimulus('ev_autoresolve');
 $oRequest->DBUpdate();
 }
 }
}

修改变更工作流

在变更关闭时执行此方法，需要修改 Change 类的工作流：

<lifecycle>
 <states>
 <state id="approved" _delta="must_exist">
 <transitions>
 <transition id="ev_finish" _delta="must_exist">
 <actions _delta="redefine">
 <action>
 <verb>SetCurrentDate</verb>
 <params>
 <param xsi:type="attcode">close_date</param>
 </params>
 </action>
 <action>
 <verb>ResolveRelatedRequest</verb>
 </action>
 </actions>
 </transition>
 </transitions>
 </state>
 </states>
</lifecycle>

完整 XML Delta

<class id="Change" _delta="must_exist">
 <methods>
 <method id="ResolveRelatedRequest" _delta="define">
 <comment>/**
 * @author My first name My last name
 * @return bool Return true on success or false to prevent the transition to happen
 */</comment>
 <static>false</static>
 <access>public </access>
 <code><![CDATA[ public function ResolveRelatedRequest()
 {
 $sOQL = "SELECT UserRequest WHERE parent_change_id = :ticket AND status != 'resolved'";
 $oRelatedRequestSet = new DBObjectSet(DBObjectSearch::FromOQL($sOQL), array(), array('ticket' => $this->GetKey()));
 while($oRequest = $oRelatedRequestSet->Fetch())
 {
 if ($oRequest->Get('status') != 'resolved' && $oRequest->Get('status') != 'closed' )
 {
 $oRequest->Set('solution', 'ticket automatically resolved by '.$this->Get('friendlyname'));
 $oRequest->ApplyStimulus('ev_autoresolve');
 $oRequest->DBUpdate();
 }
 }
 return true;
 }]]></ code>
 <arguments/>
 </method>
 </methods>
 <lifecycle>
 <states>
 <state id="approved" _delta="must_exist">
 <transitions>
 <transition id="ev_finish" _delta="must_exist">
 <actions _delta="redefine">
 <action>
 <verb>SetCurrentDate</verb>
 <params>
 <param xsi:type="attcode">close_date</param>
 </params>
 </action>
 <action>
 <verb>ResolveRelatedRequest</verb>
 </action>
 </actions>
 </transition>
 </transitions>
 </state>
 </states>
 </lifecycle>
</class>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:cascade-change-closure

版本：3_2_0/customization/cascade-change-closure.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 级联更新

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现 1:n 关系的计算字段，例如统计工单上所有工作订单的时间花费总和。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

在类 A 上定义一个"计算"字段，该字段依赖于类 B 对象上定义的数据。例如：

在工单上统计所有工作订单（1:n）的时间花费总和
在工单上统计手动添加的 CI（n:n）数量
在 FunctionalCI 上设置位置字段：PhysicalDevice 直接使用位置，Logical Device 基于运行其上的 PhysicalDevice 计算位置

需要支持：

能够搜索该"计算"字段
能够对该"计算"字段运行审计

简单策略

实现此类"计算"字段（聚合 1:n 关系中的任意字段或计数 n:n 关系）的通用策略：

为了能够查询，必须将其存储在数据库中，因此设为持久字段
为确保始终准确，需要识别何时必须重新计算并执行

在类 A 上

编写方法，基于其他字段/相关对象计算"计算"字段的值。某些情况下可直接用作 EVENT_DB_LINKS_CHANGED 的回调
在 EVENT_DB_SET_INITIAL_ATTRIBUTE_FLAGS 上的回调方法：指定"计算"字段在创建表单中隐藏
在 EVENT_DB_SET_ATTRIBUTE_FLAGS 上的回调方法：指定"计算"字段在修改时只读
EVENT_DB_LINKS_CHANGED 的回调，计算字段值并设置到对象上
将 LinkedSet 或 LinkedSetIndirect 字段的 with_php_computation XML 标志强制为 “true”

远程类无需操作，因为我们使用了事件和 with_php_computation XML 标志。

用例：1:n 求和

统计工单上所有工作订单的时间花费总和。

首先需要在 WorkOrder 和 Ticket 类上添加 time_spent 整数字段
为确保 Ticket::time_spent 始终准确，需要识别何时重新计算：
- 工单更新时
- 工作订单创建时 → 重新计算其工单
- 工作订单更新时 → 重新计算其原工单和新工单
- 工作订单删除时 → 重新计算其原工单

在 Ticket 类上

事件监听器

事件	回调方法
EVENT_DB_BEFORE_WRITE	BeforeWrite()
EVENT_DB_SET_INITIAL_ATTRIBUTES_FLAGS	HideTimeSpent()
EVENT_DB_SET_ATTRIBUTES_FLAGS	MakeTimeSpentReadOnly()
EVENT_DB_LINKS_CHANGED	ComputeTimeSpent()

激活 DB_LINKS_CHANGED

<class id="Ticket" _delta="must_exist">
 <fields>
 <field id="workorders_list">
 <with_php_computation _delta="force">true</with_php_computation>
 </field>
 </fields>
</class>

回调方法

protected function ComputeTimeSpent(?Combodo\iTop\Service\Events\EventData $oEventData)
{
 $iSum = 0;
 $oWorkOrderSet = $this->Get('workorders_list');
 while($oWorkOrder = $oWorkOrderSet->Fetch()) {
 $iSum += $oWorkOrder->Get('time_spent');
 }
 $this->Set('time_spent', $iSum);
}
public function BeforeWrite(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $aChanges = $this->ListChanges();
 if (array_key_exists('workorders_list', $aChanges)) {
 $this->ComputeTimeSpent(null);
 }
}
public function HideTimeSpent(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $this->ForceInitialAttributeFlags('time_spent', OPT_ATT_HIDDEN );
}
public function MakeTimeSpentReadOnly(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $this->ForceAttributeFlags('time_spent', OPT_ATT_READONLY);
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:cascade-update

2025/05/21 11:01 by127.0.0.1

版本：3_2_0/customization/cascade-update.txt · Last modified: 2025/05/21 11:01 by 127.0.0.1

Docs: 计划 TTO 开始

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现用户请求的"计划 TTO 开始"功能，即允许用户提前创建工单，但仅在到达计划日期后才开始计算 TTO 和 TTR。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

实现以下功能：

用户可提前创建用户请求，将其放入队列
工单仅在到达计划日期后才开始工作（TTO 和 TTR 在计划日期前不开始计时）

实现步骤

1. 添加日期字段与新状态

在 UserRequest 类中添加：

新字段 planned_date（计划日期）
新状态 scheduled（已计划）
自动刺激 ev_autoschedule 及相关转换

<classes>
 <class id="UserRequest">
 <fields>
 <!-- 添加计划日期字段 -->
 <field id="planned_date" xsi:type="AttributeDateTime" _delta="define">
 <sql>planned_date</sql>
 <is_null_allowed>true</is_null_allowed>
 <default_value/>
 </field>
 <!-- 向现有状态添加新状态值 -->
 <field id="status" _delta="must_exist">
 <values>
 <value id="scheduled" _delta="define">scheduled</value>
 </values>
 </field>
 <!-- 添加计时器以统计在此状态停留的时间 -->
 <field id="scheduledstopwatch" xsi:type="AttributeStopWatch" _delta="define">
 <states>
 <state id="scheduled">scheduled</state>
 </states>
 <working_time/>
 <thresholds/>
 <always_load_in_tables>true</always_load_in_tables>
 </field>
 </fields>
 <lifecycle>
 <stimuli>
 <!-- 添加新刺激以编程方式改变状态 -->
 <stimulus _delta="define" id="ev_autoschedule" xsi:type="StimulusInternal"/>
 </stimuli>
 <states>
 <state id="new" _delta="must_exist">
 <flags>
 <attribute id="scheduledstopwatch" _delta="define">
 <hidden/>
 </attribute>
 </flags>
 <transitions>
 <!-- 添加第一个转换：将 UserRequest 设置为 "scheduled" -->
 <transition id="ev_autoschedule" _delta="define">
 <stimulus>ev_autoschedule</stimulus>
 <target>scheduled</target>
 <actions/>
 </transition>
 </transitions>
 </state>
 <!-- 定义 "scheduled" 状态的详细信息 -->
 <state id="scheduled" _delta="define">
 <flags>
 <!-- 显示计时器（教学目的） -->
 <attribute id="scheduledstopwatch">
 <read_only/>
 </attribute>
 <!-- 防止修改计划日期 -->
 <attribute id="planned_date" _delta="define">
 <read_only/>
 </attribute>
 </flags>
 <transitions>
 <!-- 添加第二个转换：将 UserRequest 恢复为 "new" -->
 <transition id="ev_autoschedule">
 <stimulus>ev_autoschedule</stimulus>
 <target>new</target>
 <actions/>
 </transition>
 </transitions>
 <inherit_flags_from>new</inherit_flags_from>
 </state>
 <state id="assigned" _delta="must_exist">
 <flags>
 <attribute id="planned_date" _delta="define">
 <read_only/>
 </attribute>
 </flags>
 </state>
 </states>
 </lifecycle>
 <!-- 在用户请求详情中显示计时器 -->
 <presentation>
 <details _delta="must_exist">
 <items>
 <item id="col:col1">
 <items>
 <item id="fieldset:Ticket:moreinfo">
 <items>
 <item id="scheduledstopwatch" _delta="define">
 <rank>90</rank>
 </item>
 </items>
 <rank>20</rank>
 </item>
 </items>
 </item>
 </items>
 </details>
 </presentation>
 </class>
</classes>
<dictionaries>
 <dictionary id="EN US">
 <entries>
 <entry id="Class:UserRequest/Attribute:status/Value:scheduled" _delta="define">
 <![CDATA[Waiting for planned date]]>
 </entry>
 <entry id="Class:UserRequest/Stimulus:ev_autoschedule" _delta="define">
 <![CDATA[Wait for planned date]]>
 </entry>
 <entry id="Class:UserRequest/Attribute:scheduledstopwatch" _delta="define">
 <![CDATA[Scheduled stopwatch]]>
 </entry>
 </entries>
 </dictionary>
</dictionaries>

2. 自动转换

如果填写了计划日期，则在创建后自动将工单转换为 “scheduled” 状态。在 UserRequest 类中添加 PHP 方法：

protected function AfterInsert()
{
 parent::AfterInsert();
 if (!empty($this->Get('planned_date')))
 {
 $this->ApplyStimulus('ev_autoschedule');
 }
}

重要说明：

parent::AfterInsert() — 调用父类的同名方法，确保不覆盖 Ticket 类中可能已定义的逻辑
$this->Get('attribute_code') — 获取当前对象的属性值，注意属性代码必须存在，否则会报错
ApplyStimulus('stimulus_code') — 应用刺激以触发状态转换

注意：使用 OnInsert() 代替 AfterInsert() 会导致 MySQL 错误（连接过多）。

3. 到达日期后自动恢复为 “new” 状态

使用计时器的阈值功能，在目标达成时自动执行方法：

<field id="scheduledstopwatch" xsi:type="AttributeStopWatch" _delta="define">
 <states>
 <state id="scheduled">scheduled</state>
 </states>
 <goal>ScheduledStart</goal>
 <thresholds>
 <threshold id="100">
 <actions>
 <action>
 <verb>ApplyStimulus</verb>
 <params>
 <param xsi:type="string">ev_autoschedule</param>
 </params>
 </action>
 </actions>
 </threshold>
 </thresholds>
 <always_load_in_tables>true</always_load_in_tables>
</field>

定义目标计算类（放在扩展的 main.my-extension.php 中）：

class ScheduledStart implements iMetricComputer
{
 public static function GetDescription()
 {
 return "Time to wait before reopening a scheduled ticket";
 }
 public function ComputeMetric($oObject)
 {
 $iDelay = null; /* 返回 'null' 表示无目标 */
 if (MetaModel::IsValidAttCode(get_class($oObject), 'planned_date')
 && (!empty($oObject->Get('planned_date')))
 {
 $oStartDate = new DateTime();
 $oEndDate = new DateTime($oObject->Get('planned_date'));
 $iDelay = $oEndDate->format('U') - $oStartDate->format('U');
 $iDelay = ($iDelay < 0) ? 0 : $iDelay;
 }
 return $iDelay;
 }
}

注意：未定义 working_time，默认使用 24h×365d。

局限性

本教程有一些局限性，在计划用户请求（高级）中有进一步探讨。

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-activation-delay

版本：3_2_0/customization/add-activation-delay.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 计划用户请求

Fri, 27 Jun 2025 00:00:00 +0000

本文档是计划 TTO 开始教程的高级补充，探讨已识别局限性的解决方案。更多详细内容请参考 iTop 官方文档。

前提条件

探讨的问题

本教程探讨以下问题：

为什么使用 AfterInsert 而不是 iApplicationExtension
如何在创建后、处于 new 或 scheduled 状态时处理计划日期的修改
如何防止其他转换被提议

问答

为什么自动切换到 “scheduled” 状态？

这种机制也用于自动分派工单到团队和审批流程自动化。

您也可以将此转换作为用户选择提供，并在该转换上使 planned_date 字段必填。但如果与审批流程自动化结合使用，用户将无法为正在审批中的用户请求安排计划，除非在审批后安排。

创建带日期的用户请求后执行 Assign 操作导致 Fatal Error，如何避免？

扩展"自动分派工单到团队"和"审批流程自动化"会在控制台中隐藏可能导致失败的其他操作（如"Assign"、“Dispatch”、“Wait for approval"等）。

可以通过以下方式避免：

方式一：重载 DisplayBareProperties()

function DisplayBareProperties(WebPage $oPage, $bEditMode=false, $sPrefix='', $aExtraParams=array())
{
 $aFieldsMap = parent::DisplayBareProperties($oPage, $bEditMode, $sPrefix, $aExtraParams);
 if ($bEditMode && $oObject->GetState()='new')
 {
 $oPage->add_ready_script(
<<<EOF
 $('button.action[name="next_action"]').hide();
EOF
 );
 }
 return $aFieldsMap;
}

方式二：实现 iApplicationUIExtension（OnDisplayProperties()）

public function OnDisplayProperties($oObject, WebPage $oPage, $bEditMode = false)
{
 if ($bEditMode && $oObject instance of UserRequest && $oObject->GetState()='new')
 {
 $oPage->add_ready_script(
<<<EOF
 $('button.action[name="next_action"]').hide();
EOF
 );
 }
}

覆盖风险

定义 DBObject 可覆盖方法时，需注意标准 iTop 数据模型中可能已定义了相同方法。如果在 setup/toolkit 编译时添加 _delta="define" 的方法已存在，将会失败。此时可以使用 “redefine”，但必须镜像现有代码，否则会破坏 iTop 的当前行为。

标准数据模型中 UserRequest 类已定义的方法示例：

public function ComputeValues()
{
 $this->Set('priority', $this->ComputePriority());
 return parent::ComputeValues();
}
public function DoCheckToWrite()
{
 parent::DoCheckToWrite();
 if (!$this->IsNew() && ($this->Get('parent_request_id') == $this->GetKey()))
 { $this->m_aCheckIssues[] = Dict::Format('Class:UserRequest/Error:CannotAssignParentRequestIdToSelf'); }
}
protected function OnInsert()
{
 $this->ComputeImpactedItems();
 $this->SetIfNull('last_update', time());
 $this->SetIfNull('start_date', time());
}
protected function OnUpdate()
{
 parent::OnUpdate();
 $aChanges = $this->ListChanges();
 if (array_key_exists('functionalcis_list', $aChanges))
 { $this->UpdateImpactedItems(); }
 $this->Set('last_update', time());
 $this->UpdateChildRequestLog();
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-activation-delay2

版本：3_2_0/customization/add-activation-delay2.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 计算工单结束日期

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中自动计算工作订单（WorkOrder）的结束日期，即开始日期加固定延迟（如 2 小时）。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

自动计算工作订单的结束日期，为其开始日期加上固定的 2 小时延迟。

实现方式

使用 Designer：需要具有 Designer PHP developer 权限
使用扩展：需要已创建扩展

前提条件

默认情况下，WorkOrder 的结束日期是必填的。我们需要更改此逻辑，因为该数据将在保存后自动设置。

使用 Designer

在 Designer 中修改 WorkOrder 类的 end_date 字段，将 is_null_allowed 设为 true。

使用扩展

<class id="WorkOrder" _delta="must_exist">
 <fields>
 <field id="end_date">
 <is_null_allowed _delta="redefine">true</is_null_allowed>
 </field>
 </fields>
</class>

计算选项

计算无法通过 XML 完成，需要添加 PHP 方法。可以选择以下事件：

事件	可能的回调方法名
创建或更新前（EVENT_DB_BEFORE_WRITE）	`EvtBeforeWrite(Combodo\iTop\Service\Events\EventData $oEventData)`
重新计算对象值（EVENT_DB_COMPUTE_VALUES）	`EvtComputeValues(Combodo\iTop\Service\Events\EventData $oEventData)`

创建或更新前

回调方法

在创建或修改时，如果用户修改了开始日期，结束日期必须自动重新计算：

public function EvtBeforeWrite(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $oStartDate = new DateTime($this->Get('start_date'));
 $oEndDate = clone $oStartDate;
 $iDuration = 2*3600 ; // 2 小时（秒）
 $oEndDate->modify( '+'.$iDuration.' seconds');
 $this->Set('end_date',$oEndDate->Format(AttributeDateTime::GetInternalFormat()));
}

添加事件监听器

<class id="WorkOrder">
 <event_listeners>
 <event_listener id="EvtBeforeWrite" _delta="define">
 <event>EVENT_DB_BEFORE_WRITE</event>
 <rank>10</rank>
 <callback>EvtBeforeWrite</callback>
 </event_listener>
 </event_listeners>
</class>

重新计算对象值

另一个可用于计算字段的事件。逻辑与上述完全相同。

回调方法

public function EvtComputeValues(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $oStartDate = new DateTime($this->Get('start_date'));
 $oEndDate = clone $oStartDate;
 $iDuration = 2*3600 ; // 2 小时（秒）
 $oEndDate->modify( '+'.$iDuration.' seconds');
 $this->Set('end_date',$oEndDate->Format(AttributeDateTime::GetInternalFormat()));
}

添加事件监听器

<class id="WorkOrder">
 <event_listeners>
 <event_listener id="EvtComputeValues" _delta="define">
 <event>EVENT_DB_COMPUTE_VALUES</event>
 <rank>10</rank>
 <callback>EvtComputeValues</callback>
 </event_listener>
 </event_listeners>
</class>

设置字段只读

防止用户输入结束日期，因为上面已通过计算强制设置了其值。

回调方法

创建两个方法，分别控制创建表单和修改表单：

public function evtSetInitialAttributeFlags(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $this->ForceInitialAttributeFlags('end_date', OPT_ATT_READONLY);
}
public function evtSetAttributeFlags(Combodo\iTop\Service\Events\EventData $oEventData)
{
 $this->ForceAttributeFlags('end_date', OPT_ATT_READONLY);
}

添加事件监听器

<class id="WorkOrder">
 <event_listeners>
 <event_listener id="evtSetInitialFlags" _delta="define">
 <event>EVENT_DB_SET_INITIAL_ATTRIBUTES_FLAGS</event>
 <rank>10</rank>
 <callback>evtSetInitialFlags</callback>
 </event_listener>
 <event_listener id="evtSetAttributeFlags" _delta="define">
 <event>EVENT_DB_SET_ATTRIBUTES_FLAGS</event>
 <rank>10</rank>
 <callback>evtSetAttributeFlags</callback>
 </event_listener>
 </event_listeners>
</class>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:compute-field

2025/05/16 15:23 by127.0.0.1

版本：3_2_0/customization/compute-field.txt · Last modified: 2025/05/16 15:23 by 127.0.0.1

Docs: 将工单传输到另一个 iTop

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何使用 Webhook 和 REST Web 服务将工单从一个 iTop 实例传输到另一个 iTop 实例（如合作伙伴）。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

场景

将您的 iTop 与合作伙伴的 iTop 实例互联，当特定工单需要由他们在其 iTop 中处理时，实现以下场景：

识别需要传输的工单：支持代理识别需要提交给使用 iTop 的合作伙伴的工单，将工单移至特定状态并选择适当的合作伙伴
传输工单：工单进入特定状态时，触发 iTop Webhook 调用，在合作伙伴 iTop 中创建复制工单
推送更多详情：当您的私有日志更新时，推送到合作伙伴工单
获取合作伙伴反馈：当合作伙伴工单公共日志更新时，镜像到您的私有日志
工单解决：合作伙伴工单解决时，重新分配您的工单，并将合作伙伴解决方案复制到您的私有日志

识别需要传输的工单

需要在 UserRequest 上添加 partner_id 外键字段，以选择应处理问题的合作伙伴：

<field id="partner_id" xsi:type="AttributeExternalKey" _delta="define">
 <sql>partner_id</sql>
 <filter>SELECT Organization WHERE category='partner'</filter>
 <dependencies/>
 <is_null_allowed>true</is_null_allowed>
 <target_class>Organization</target_class>
 <on_target_delete>DEL_AUTO</on_target_delete>
 <tracking_level>all</tracking_level>
</field>

修改 UserRequest 生命周期：

创建新状态 “Pending partner”（代码 pending_partner）
创建 ev_pendingpartner 刺激和从 “Assigned” 到 “Pending partner” 的转换，该转换必须提示必填的 partner_id
创建 ev_partnerupdate 刺激和从 “Pending partner” 回到 “Assigned” 的转换，由合作伙伴使用 REST 服务触发

传输工单

为便于更新对方 iTop 工单，最简单的方式是在 UserRequest 上存储远程 ID。双方 iTop 都需要添加 remote_ticketid 字段：

<field id="remote_ticketid" xsi:type="AttributeInteger" _delta="define">
 <sql>remote_ticketid</sql>
 <default_value>0</default_value>
 <is_null_allowed>false</is_null_allowed>
 <tracking_level>all</tracking_level>
</field>

触发器

在您的 iTop 上创建触发器（进入状态时）：“Pending partner”，过滤器：

SELECT UserRequest WHERE remote_ticketid = 0

iTop Webhook 调用

创建 iTop Webhook 调用，链接到上述触发器，在合作伙伴 iTop 上复制工单。

远程 iTop 连接

合作伙伴需要提供一个具有 REST 访问权限的 iTop 用户，权限可限制为特定组织和角色。访问权限必须包括：

至少读取 Organization、Contact 和 Ticket
对用户请求的写入权限

JSON 数据

提供在合作伙伴 iTop 上创建用户请求的 JSON 数据：

{
 "operation":"core/create",
 "comment":"Ticket transfer by Combodo",
 "class":"UserRequest",
 "output_fields":"id, friendlyname",
 "fields":
 {
 "org_id":"SELECT Organization WHERE name = 'Combodo'",
 "caller_id":{"name":"Combodo","first_name":"Support"},
 "title":"$this->title$",
 "description":"$this->description$",
 "public_log":"$this->private_log$",
 "remote_ticketid":"$this->id$"
 }
}

处理响应回调

创建 SetExternalID 方法处理响应，存储远程工单 ID：

public function SetExternalID($oResponse,$oAction)
{
 $sBodyAsJSON = $oResponse->GetBody();
 $aBody = json_decode($sBodyAsJSON, true);

 if (false === $aBody) {
 throw new Exception('Could not process response as it is not a valid JSON string: '.$sBodyAsJSON);
 }
 if (false === isset($aBody['objects'][0]['key'])) {
 throw new Exception('Could not retrieve external ID') ;
 }
 $sExternalID = $aBody['objects'][0]['key'];
 $this->Set('remote_ticketid', $sExternalID);
 $this->DBUpdate();
}

推送更多详情

当请求者或代理向工单添加信息时，自动镜像到合作伙伴工单。

触发器

在您的 iTop 上创建触发器（对象更新时），当公共和私有日志字段修改时触发。

iTop Webhook 调用

创建另一个 iTop Webhook 调用，链接到上述触发器，更新合作伙伴 iTop 上的工单。

JSON 数据

{
 "operation":"core/update",
 "comment":"Ticket update by Combodo",
 "class":"UserRequest",
 "key":"$this->remote_ticketid$",
 "output_fields":"id, friendlyname",
 "fields":
 {
 "public_log":"$this->head(private_log)$"
 }
}

获取合作伙伴反馈

合作伙伴更新其公共日志时，将回复镜像到您的私有日志。

您需要向合作伙伴提供一个具有 REST 访问权限的 iTop 用户，允许读取和更新已传输的用户请求。

合作伙伴需要在其 iTop 上创建：

连接到您 iTop 的远程 iTop 连接
**触发器（对象更新时）**和链接的 iTop Webhook 调用

JSON 数据注意公共和私有日志的反转：

{
 "operation":"core/update",
 "comment":"Ticket update by Partner",
 "class":"UserRequest",
 "key":"$this->remote_ticketid$",
 "output_fields":"id, friendlyname",
 "fields":
 {
 "private_log":"$this->head(public_log)$"
 }
}

工单解决

合作伙伴解决其工单时，您的工单应重新分配给代理，并附带评论。

在合作伙伴 iTop 上

创建触发器（进入状态时）：“Resolved”，过滤器 SELECT UserRequest WHERE remote_ticketid > 0
创建 iTop Webhook 调用，应用 ev_partnerupdate 刺激并更新您的私有日志

{
 "operation":"apply_stimulus",
 "comment":"Ticket update by Combodo",
 "class":"UserRequest",
 "key":"$this->remote_ticketid$",
 "stimulus": "ev_partnerupdate",
 "output_fields":"id, friendlyname",
 "fields":
 {
 "private_log":"$this->solution$"
 }
}

在您的 iTop 上

添加触发器（进入状态时）：“Assigned”，过滤器 SELECT UserRequest WHERE STATUS = 'pending_partner'

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:itop-webhook

2024/09/10 10:25 by127.0.0.1

版本：3_2_0/customization/itop-webhook.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 数据同步

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中编写和配置数据收集器，从外部应用同步数据到 iTop。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉数据同步参考

概述

收集器（Collector）是一个独立的 PHP 应用程序，从源应用程序获取数据并定期推送到 iTop 中，例如每天运行。它是一个简单的 ETL（提取/转换/加载）应用程序。

您无需编写完整应用程序，可以下载并使用已编写的大部分代码进行增强。

关键问题

如何从源应用程序获取数据？

直接查询数据库（SQL）？
使用 REST 和 Web 服务（JSON 格式）？
直接使用应用程序生成的 CSV 文件？
使用其他类型的 Web 服务（如 ripcord）？

对于前 3 种方法，SDK 中已存在预定义的收集器，编写自己的收集器主要是编写配置文件。对于最后一种情况，需要在 PHP 中做更多工作。

在哪个服务器上安装收集器？

收集器是独立应用程序，需要由 cron 定期启动
收集器必须能够访问源应用程序的数据
收集器必须能够 Web 访问 iTop 的 Web 服务，但不需要在同一台机器上
收集器必须符合数据收集器基础 - 要求

示例场景

假设您希望用应用程序 “Blabla” 中的 Sites 信息来填充 iTop 中的 Locations 对象。您可以通过 REST/JSON 获取 Blabla 的 Sites 信息。

创建收集器

在收集器服务器上：

下载并解压数据收集器基础包
在该机器上创建 PHP 文件 /collectors/sitescollector.class.inc.php：

<?php
class SiteCollector extends JsonCollector
{
}

创建另一个文件 /collectors/main.php：

<?php
require_once(APPROOT.'collectors/sitecollector.class.inc.php');
Orchestrator::AddCollector(1, 'sitecollector');

更新文件 /conf/params.local.xml，设置以下 3 个参数：

<itop_url>https://????/</itop_url>
<itop_login>????</itop_login>
<itop_password>????</itop_password>

定义 iTop 端

在 iTop 上创建数据同步 “Locations from Blabla”，以同步来自 Blabla 应用程序的 Sites 数据。创建时考虑：

Blabla 应用程序中 Site 对象有哪些可用信息（字段）？
哪些需要同步？
应该创建新 Location 还是仅更新现有 Location？

定义映射

在收集器服务器上运行以下命令：

php toolkit/dump_tasks.php --task_name="Location from Blabla" > collectors/SitesCollector.json

它提取同步数据源的定义，允许收集器强制其存在和行为。

创建的 collectors/SitesCollector.json 文件称为 JSON 定义文件，包含在 iTop 上自动创建或更新数据同步源所需的信息。

定义映射逻辑

编写 XML 文件指定 Blabla Sites 数据格式与 iTop Location 对象之间的映射逻辑。由于使用 JSON，需要定义：

标签	用途
`<json_data>`	用于从 Blabla 应用程序获取 Site 对象及每个对象的字段集。此部分完全取决于 Blabla 应用程序提供的 REST/JSON 接口
`<path>`	指定如何在 Blabla 返回的 JSON 响应中检索字段代码和值。支持的语法仅限于用 `/` 分隔的标签名。标签可以是 JSON 返回文件中的真实标签，或对于无标签级别（如表格）使用 `*`
`<fields>`	为每个 iTop 字段指定对应的 Blabla 字段。其中特殊必填标签 `<primary_key>` 必须映射到在 Blabla 应用程序中唯一标识 Site 的字段
`<defaults>`	允许为 iTop 字段指定固定值。可与映射组合使用，用于特定 Blabla Site 没有该字段值的情况

这些信息必须在 conf/params.distrib.xml 文件的 <parameters> 标签下添加：

<parameters>
 <!-- 收集器类名小写 -->
 <sitecollector>
 <jsonurl>http://blabla.demo.com/webservices/rest.php</jsonurl>
 <jsonpost>
 <auth_user>blabla-rest-user</auth_user>
 <auth_pwd>blabla-rest-user-password</auth_pwd>
 <json_data>
 <!--
 此部分完全取决于 Blabla 应用程序提供的 REST/JSON 接口
 -->
 </json_data>
 <version>1.3</version>
 </jsonpost>
 <!-- "path" 指定如何在 JSON 响应中检索字段 -->
 <path>objects/*/fields</path>
 <fields>
 <primary_key>blabla_id</primary_key> <!-- primary_key 标签必填 -->
 <name>name</name>
 <country>land</country>
 <status>step</status>
 </fields>
 <defaults> <!-- 允许为 iTop Location 字段指定默认值 -->
 <org_id>Demo</org_id>
 <status>active</status>
 </defaults>
 </sitecollector>
</parameters>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:synchronize-data

版本：3_2_0/customization/synchronize-data.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 添加生命周期状态

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 的用户请求生命周期中添加新状态（如"等待第三方"），并使用计时器统计在该状态停留的时间。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

跟踪每张工单等待第三方提供商的时间，需要：

在 UserRequest 类上添加计时器属性，统计工单处于 pending_provider 状态的时间
添加子项字段以显示等待提供商的时间
仅在特定状态下显示等待第三方的总时间

假设已添加 pending_provider 状态和相关转换。

使用 ITSM Designer（仅限 Combodo 客户）

添加计时器

点击底部面板"Stopwatches"标题旁的小按钮创建计时器
输入代码、标签，选择计时器运行的状态（此处为 pending_provider）

跟踪时间

在 UserRequest 类上点击新建字段图标：

字段 = pending_provider_delay
类型 = Stopwatch Value
计时器 = 选择 pending_provider
值 = Total time spent

显示计时器

将该字段添加到展示/详情视图中。在 Schema 标签中选择 pending_provider_delay 字段，在计时器不相关的状态中隐藏此字段。

使用 iTop 扩展

添加计时器

<!-- 添加计时器以统计在此状态停留的时间 -->
<field id="providerstopwatch" xsi:type="AttributeStopWatch" _delta="define">
 <states>
 <state id="pending_provider">pending_provider</state>
 </states>
 <working_time/>
 <thresholds/>
 <always_load_in_tables>true</always_load_in_tables>
</field>

<entry id="Class:UserRequest/Attribute:providerstopwatch" _delta="define">
 <![CDATA[Provider stopwatch]]>
</entry>

跟踪时间

此步骤必须执行，才能在表单中显示该信息并通过 OQL 查询。

<!-- 声明此计时器子项是显示或查询所必需的 -->
<field id="pending_provider_delay" xsi:type="AttributeSubItem" _delta="define">
 <target_attcode>providerstopwatch</target_attcode>
 <item_code>timespent</item_code>
</field>

可用的子项代码：timespent、started、laststart、stopped

<entry id="Class:UserRequest/Attribute:pending_provider_delay" _delta="define">
 <![CDATA[Provider time spent]]>
</entry>

显示计时器

在详情中显示计时器本身（仅用于理解其行为）：

<presentation>
 <details _delta="must_exist">
 <items>
 <item id="col:col0">
 <items>
 <item id="fieldset:Ticket:moreinfo">
 <items>
 <item id="pending_provider_delay" _delta="define">
 <rank>80</rank>
 </item>
 <item id="providerstopwatch" _delta="define">
 <rank>90</rank>
 </item>
 </items>
 <rank>20</rank>
 </item>
 </items>
 </item>
 </items>
 </details>
</presentation>

显示时间

时间仅在计时器停止时计算，因此：

不应在 pending_provider 状态中显示（信息不准确）
在 new 状态中不显示（无用且为空）
在工单已解决或关闭时显示，设为只读

<lifecycle>
 <states>
 <state id="new" _delta="must_exist">
 <flags>
 <attribute id="pending_provider_delay" _delta="define">
 <hidden/>
 </attribute>
 </flags>
 </state>
 <state id="resolved" _delta="must_exist">
 <flags>
 <attribute id="pending_provider_delay" _delta="define">
 <read_only/>
 </attribute>
 </flags>
 </state>
 </states>
</lifecycle>

完整 XML

<classes>
 <class id="UserRequest">
 <fields>
 <field id="status" _delta="must_exist">
 <values>
 <value id="pending_provider" _delta="define">pending_provider</value>
 </values>
 </field>
 <field id="providerstopwatch" xsi:type="AttributeStopWatch" _delta="define">
 <states>
 <state id="pending_provider">pending_provider</state>
 </states>
 <working_time/>
 <thresholds/>
 <always_load_in_tables>true</always_load_in_tables>
 </field>
 <field id="pending_provider_delay" xsi:type="AttributeSubItem" _delta="define">
 <target_attcode>providerstopwatch</target_attcode>
 <item_code>timespent</item_code>
 </field>
 </fields>
 <lifecycle>
 <stimuli>
 <stimulus _delta="define" id="ev_pending_provider" xsi:type="StimulusUserAction"/>
 </stimuli>
 <states>
 <state id="assigned" _delta="must_exist">
 <transitions>
 <transition id="ev_pending_provider" _delta="define">
 <stimulus>ev_pending_provider</stimulus>
 <target>pending_provider</target>
 <actions/>
 </transition>
 </transitions>
 </state>
 <state id="pending_provider" _delta="define">
 <flags />
 <transitions>
 <transition id="ev_assign">
 <stimulus>ev_assign</stimulus>
 <target>assigned</target>
 <actions/>
 </transition>
 </transitions>
 <inherit_flags_from>assigned</inherit_flags_from>
 </state>
 <state _delta="must_exist" id="new">
 <flags>
 <attribute id="pending_provider_delay" _delta="define">
 <hidden/>
 </attribute>
 </flags>
 </state>
 <state id="resolved" _delta="must_exist">
 <flags>
 <attribute id="pending_provider_delay" _delta="define">
 <read_only/>
 </attribute>
 </flags>
 </state>
 </states>
 </lifecycle>
 <presentation>
 <details _delta="must_exist">
 <items>
 <item id="col:col0">
 <items>
 <item id="fieldset:Ticket:moreinfo">
 <items>
 <item id="pending_provider_delay" _delta="define">
 <rank>80</rank>
 </item>
 <item id="providerstopwatch" _delta="define">
 <rank>90</rank>
 </item>
 </items>
 <rank>20</rank>
 </item>
 </items>
 </item>
 </items>
 </details>
 </presentation>
 </class>
</classes>
<dictionaries>
 <dictionary id="EN US">
 <entries>
 <entry id="Class:UserRequest/Attribute:status/Value:pending_provider" _delta="define">
 <![CDATA[Pending provider]]>
 </entry>
 <entry id="Class:UserRequest/Attribute:pending_provider_delay" _delta="define">
 <![CDATA[Provider time spent]]>
 </entry>
 <entry id="Class:UserRequest/Stimulus:ev_pending_provider" _delta="define">
 <![CDATA[Wait for Provider]]>
 </entry>
 <entry id="Class:UserRequest/Attribute:providerstopwatch" _delta="define">
 <![CDATA[Provider stopwatch]]>
 </entry>
 </entries>
 </dictionary>
</dictionaries>

计时器行为

计时器在不同阶段的状态：

阶段	状态	说明
1. 从未启动	停止	Elapsed 不可用
2. 首次进入 Pending provider	运行中	Elapsed 不可用；Started = LastStart
3. 首次返回 Assigned	停止	Elapsed 可用；LastStart 为空；Stopped 已记录
4. 再次进入 Pending provider	运行中	Elapsed 不可用；Started 不变；LastStart 为最新启动时间
5. 再次返回 Assigned	停止	Elapsed 可用；LastStart 为空；Stopped 记录最新停止时间

注意：Elapsed 不等于 Started 与 Stopped 的差值，因为计时器可能多次启动和停止。

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-state

Last modified: 2024/09/10 10:25 by127.0.0.1

版本：3_2_0/customization/add-state.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 统计工单重开次数

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中统计用户请求被重开的次数。更多详细内容请参考 iTop 官方文档。

目标

统计用户请求被重开的次数。需要完成：

向 UserRequest 添加计数器字段
停用历史追踪（可选）
修改 UserRequest 生命周期，在从 resolved 到 assigned 的转换时调用方法
修改展示以显示计数器
添加计数器字段的标签

使用 ITSM Designer（仅限 Combodo 客户）

添加字段

进入 UserRequest 类，Schema 标签
创建新字段：
- 字段代码：reopen_counter（仅小写字母，无空格、破折号或其他非字母字符）
- 类型：Number (Integer)
- 定义标签
- 停用历史追踪（可选）

修改生命周期

进入 Lifecycle 标签
在图中选择从 resolved 到 assigned 的转换
在右侧面板，点击动作列表底部按钮
在对话框中：
- 选择方法 AddValue
- 在 Target field 中选择 reopen_counter
- 在 Value 中输入 1

修改展示

进入 Presentation 标签，将 reopen_counter 添加到 Console 中 UserRequest 的详情中。

使用 iTop 扩展

添加计数器字段

<classes>
 <class id="UserRequest" _delta="must_exist">
 <fields>
 <field id="reopen_count" xsi:type="AttributeInteger" _delta="define">
 <sql>reopen_count</sql>
 <default_value>0</default_value>
 <is_null_allowed>true</is_null_allowed>
 </field>
 </fields>
 </class>
</classes>

停用历史追踪

如果认为记录 reopen_count 计数器的每次变更在历史中无用，可以添加 <tracking_level>none</tracking_level> 到字段定义中。

<field id="reopen_count">
 <tracking_level>none</tracking_level>
</field>

适用场景：

不断变化的值，由外部来源控制
计算计数器，其修改日期可能无用

在转换时调用方法

每次工单从 resolved 移动到 assigned 状态时增加计数器：

<state id="resolved">
 <transitions>
 <transition id="ev_reopen">
 <actions _delta="redefine">
 <action>
 <verb>AddValue</verb>
 <params>
 <param xsi:type="attcode">reopen_count</param>
 <param xsi:type="int">1</param>
 </params>
 </action>
 </actions>
 </transition>
 </transitions>
</state>

声明 PHP 方法

如果所需方法不在可用方法中，可以创建自己的方法：

public function MyLifecycleMethod($sAttCode, $iIncrement=1)
{
 if (MetaModel::IsValidAttCode(get_class($this), $sAttCode)
 && is_numeric($iIncrement)
 && (MetaModel::GetAttributeDef(get_class($this),$sAttCode) instanceof AttributeInteger))
 {
 $iNew = $this->Get($sAttCode) + $iIncrement;
 $this->Set($sAttCode, $iNew);
 }
 return true;
}

PHP 方法需要嵌入在 XML 结构中。

添加计数器到展示

将 reopen_count 添加到 UserRequest 详情页的第 3 列，SLA report 字段集中：

<class id="UserRequest" _delta="must_exist">
 <presentation>
 <details>
 <items>
 <item id="col:col3">
 <items>
 <item id="fieldset:Ticket:SLA">
 <items>
 <item id="reopen_count" _delta="define">
 <rank>80</rank>
 </item>
 </items>
 </item>
 </items>
 </item>
 </items>
 </details>
 </presentation>
</class>

添加计数器标签

<entry id="Class:UserRequest/Attribute:reopen_count" _delta="define">Reopening counter</entry>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-counter

版本：3_2_0/customization/add-counter.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 延迟后自动关闭

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中实现工单在"冻结"状态停留超过指定天数后自动关闭的功能。更多详细内容请参考 iTop 官方文档。

前提条件

熟悉教程中使用的语法
已创建扩展

目标

自动关闭在 frozen 状态停留超过 21 天的工单。

需要完成：

添加带阈值和目标的计时器
编写计算方法
定义触发器和通知（可选，用于在自动关闭前通知客户）
客户回复且工单退出 frozen 状态时，重置计数器

添加计时器

在 UserRequest 类上添加计时器字段：

定义计时器运行的状态：frozen
使用 DefaultWorkingTimeComputer（默认 24×7，不关心业务时间和周末假期）
定义三个阈值（33%、66%、100%），可用于后续的触发器和通知
在 100% 阈值时，自动关闭工单

将以下内容放入扩展的 datamodel.my-extension.xml 文件中：

<field id="pending_customer_stopwatch" xsi:type="AttributeStopWatch" _delta="define">
 <states>
 <state id="frozen">frozen</state>
 </states>
 <working_time>DefaultWorkingTimeComputer</working_time>
 <thresholds>
 <threshold id="33">
 <actions/>
 </threshold>
 <threshold id="66">
 <actions/>
 </threshold>
 <threshold id="100">
 <actions>
 <action>
 <verb>ApplyStimulus</verb>
 <params>
 <param xsi:type="string">ev_resolve</param>
 </params>
 </action>
 </actions>
 </threshold>
 </thresholds>
 <always_load_in_tables>true</always_load_in_tables>
 <goal>ComputePendingDelay</goal>
</field>

计算方法

将以下内容放入扩展的 main.my-extension.php 文件中：

class ComputePendingDelay implements iMetricComputer
{
 public static function GetDescription()
 {
 return "Used to compute delay when pending caller";
 }
 public function ComputeMetric($oObject)
 {
 $iDelay = MetaModel::GetModuleSetting('itop-request-mgmt', 'pending_delay', '21');
 $iRes = $iDelay * 86400; // 天数 × 每天 86400 秒
 return $iRes;
 }
}

定义通知

使用上述示例，您可以创建触发器（基于阈值）和动作，当用户请求达到目标的 33%、66% 或 100% 时执行。这意味着您可以在不同阈值级别使用不同的邮件内容。

重置计数器

在退出 frozen 状态的任何转换上，可以重置计数器：

<state id="frozen" _delta="define">
 <flags>...</flags>
 <transitions>
 <transition id="ev_autoresolve">
 <stimulus>ev_autoresolve</stimulus>
 <target>resolved</target>
 <actions>
 <action>
 <verb>ResetStopWatch</verb>
 <params>
 <param xsi:type="attcode">pending_customer_stopwatch</param>
 </params>
 </action>
 </actions>
 </transition>
 </transitions>
</state>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:auto-close

版本：3_2_0/customization/auto-close.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 移除历史追踪

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中为计数器字段停用历史追踪。更多详细内容请参考 iTop 官方文档。

目标

为计数器字段停用历史追踪，避免在历史记录中记录每次计数器变更。

适用场景

不断变化的值，由外部来源控制
计算计数器，其修改日期可能无用

实现方法

向字段定义添加 <tracking_level>none</tracking_level>：

<field id="reopen_count">
 <!-- 无追踪级别，表示该字段的变更不记录在历史日志中 -->
 <tracking_level>none</tracking_level>
</field>

如果不定义该标签，iTop 将默认追踪该字段的变更。

完整示例

在统计工单重开次数教程中，完整的计数器字段定义如下：

<classes>
 <class id="UserRequest" _delta="must_exist">
 <fields>
 <field id="reopen_count" xsi:type="AttributeInteger" _delta="define">
 <sql>reopen_count</sql>
 <default_value>0</default_value>
 <is_null_allowed>true</is_null_allowed>
 <tracking_level>none</tracking_level>
 </field>
 </fields>
 </class>
</classes>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-counter#deactivate_history_tracking

版本：3_2_0/customization/add-counter.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 重开计数器

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在 iTop 中统计用户请求被重开的次数。更多详细内容请参考 iTop 官方文档。

目标

统计用户请求被重开的次数。需要完成：

向 UserRequest 添加计数器字段
停用历史追踪（可选）
修改 UserRequest 生命周期，在从 resolved 到 assigned 的转换时调用方法
修改展示以显示计数器
添加计数器字段的标签

使用 ITSM Designer（仅限 Combodo 客户）

添加字段

进入 UserRequest 类，Schema 标签
创建新字段：
- 字段代码：reopen_counter（仅小写字母，无空格、破折号或其他非字母字符）
- 类型：Number (Integer)
- 定义标签
- 停用历史追踪（可选）

修改生命周期

进入 Lifecycle 标签
在图中选择从 resolved 到 assigned 的转换
在右侧面板，点击动作列表底部按钮
在对话框中：
- 选择方法 AddValue
- 在 Target field 中选择 reopen_counter
- 在 Value 中输入 1

修改展示

进入 Presentation 标签，将 reopen_counter 添加到 Console 中 UserRequest 的详情中。

使用 iTop 扩展

添加计数器字段

<classes>
 <class id="UserRequest" _delta="must_exist">
 <fields>
 <field id="reopen_count" xsi:type="AttributeInteger" _delta="define">
 <sql>reopen_count</sql>
 <default_value>0</default_value>
 <is_null_allowed>true</is_null_allowed>
 </field>
 </fields>
 </class>
</classes>

停用历史追踪

如果认为记录 reopen_count 计数器的每次变更在历史中无用，可以添加 <tracking_level>none</tracking_level> 到字段定义中。

<field id="reopen_count">
 <tracking_level>none</tracking_level>
</field>

适用场景：

不断变化的值，由外部来源控制
计算计数器，其修改日期可能无用

在转换时调用方法

每次工单从 resolved 移动到 assigned 状态时增加计数器：

<state id="resolved">
 <transitions>
 <transition id="ev_reopen">
 <actions _delta="redefine">
 <action>
 <verb>AddValue</verb>
 <params>
 <param xsi:type="attcode">reopen_count</param>
 <param xsi:type="int">1</param>
 </params>
 </action>
 </actions>
 </transition>
 </transitions>
</state>

声明 PHP 方法

如果所需方法不在可用方法中，可以创建自己的方法：

public function MyLifecycleMethod($sAttCode, $iIncrement=1)
{
 if (MetaModel::IsValidAttCode(get_class($this), $sAttCode)
 && is_numeric($iIncrement)
 && (MetaModel::GetAttributeDef(get_class($this),$sAttCode) instanceof AttributeInteger))
 {
 $iNew = $this->Get($sAttCode) + $iIncrement;
 $this->Set($sAttCode, $iNew);
 }
 return true;
}

PHP 方法需要嵌入在 XML 结构中。

添加计数器到展示

将 reopen_count 添加到 UserRequest 详情页的第 3 列，SLA report 字段集中：

<class id="UserRequest" _delta="must_exist">
 <presentation>
 <details>
 <items>
 <item id="col:col3">
 <items>
 <item id="fieldset:Ticket:SLA">
 <items>
 <item id="reopen_count" _delta="define">
 <rank>80</rank>
 </item>
 </items>
 </item>
 </items>
 </item>
 </items>
 </details>
 </presentation>
</class>

添加计数器标签

<entry id="Class:UserRequest/Attribute:reopen_count" _delta="define">Reopening counter</entry>

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:add-counter

版本：3_2_0/customization/add-counter.txt · Last modified: 2024/09/10 10:25 by 127.0.0.1

Docs: 日志更新时重新分配工单

Fri, 27 Jun 2025 00:00:00 +0000

本文档介绍如何在客户更新工单日志时自动重新分配工单。更多详细内容请参考 iTop 官方文档。

目标

在本教程中，我们将了解当客户在门户工单案例日志中输入新条目时，如何强制自动将用户请求重新分配给处理人的不同解决方案。

通常，当客户在用户门户中提供信息或询问有关正在进行的工单的问题时，我们希望工单处理人能够知晓并响应工单，最简单的方式就是重新分配工单。使用 “Mail To Ticket Automation” 扩展可以相对容易地配置此功能，但在门户中则不然。

有多种方式可以实现。这里提供 2 种方法：

强制门户用户通过转换更新日志，该转换将重新分配工单
检查日志是否在门户中更新，并触发后台转换

通过转换更新

在 pending 状态下拒绝案例日志编辑

使用事件和 PHP 回调方法，在以下情况下使案例日志只读：

在门户中
处于 pending 状态
不在转换中

/**
 * EVENT_DB_SET_ATTRIBUTES_FLAGS 的事件监听器
 */
public function EvtSetAttributesFlags(Combodo\iTop\Service\Events\EventData $oEventData)
{
 // $oEventData->Get('target_state') 如果不在转换中返回 null，否则提供转换的目标状态
 if (ContextTag::Check('GUI:Portal') && ($this->Get('status') === 'pending') && ($oEventData->Get('target_state') == null)) {
 $this->AddAttributeFlags('public_log', OPT_ATT_READONLY);
 }
}

更改从 pending 到 assigned 的转换所使用的激励，将 ev_assign 替换为 ev_reopen，这是允许门户用户使用的激励。
在转换中强制编辑案例日志（必须提示）

后台强制转换

使用 EVENT_DB_AFTER_WRITE 事件和回调方法，如果条件匹配，则应用适当的激励以重新分配工单。

public function EvtAfterWriteUserRequest(Combodo\iTop\Service\Events\EventData $oEventData)
{
 // 不在创建中，也不在转换中
 if (!$oEventData->Get('is_new') && $oEventData->Get('stimulus_applied') === null) {
 $sStatus = $this->Get('status');
 if (ContextTag::Check('GUI:Portal') && in_array($sStatus, ['pending', 'resolved'])) {
 // 此操作期间所做的更改列表
 $aChanges = $oEventData->Get('changes') ?? [];
 if (array_key_exists('public_log', $aChanges))
 {
 $sStimulus = ($sStatus === 'resolved') ? 'ev_reopen' : 'ev_assign';
 $this->ApplyStimulus($sStimulus);
 }
 }
 }
}

原文：https://www.itophub.io/wiki/page?id=3_2_0:customization:reassign-on-log-update

版本：3_2_0/customization/reassign-on-log-update.txt · Last modified: 2025/08/12 14:41 by 127.0.0.1