流程自动化审批

名称:自动化审批流程
说明:基于服务目录的预定义规则来控制您的审批流程
版本:1.4.5
发布日期:2019-03-26
iTop版本要求(最低):2.4.0
代码:combodo-approval-process-automation
状态:稳定版

 别名:审批扩展
传播:iTop Hub

对于老的2.2.0之前的iTop版本使用1.1.3.
对于iTop 2.2.x 或者 2.3.x,使用1.2.2 或者最好使用 1.3.5
对于iTop 2.4.0 或者更高,使用当前版本或以上

此模块提供处理用户请求的两级审批流程的功能,每个级别上有多个并行审批人。

特性

基于规则的自动化审批机制。

支持被动或主动审批和超时延迟的配置。

两个级别的审批人在各自的级别并行进行审批。

批准者可以通过电子邮件一次点击批准或拒绝请求(无需拥有iTop帐户),也可以在控制台上批准多个待批准的请求。

每个工单上审批状态的图形视图。

可配置的审批电子邮件消息,具有多语言功能。

修订历史

发布日期版本内容
2020-03-182.0.1* 带兼容性iTop 2.7
* 当试图打开的对象形式时,找不到解决TWIG模板
2020-03-052.0.0* 添加兼容性与iTop 2.7+
* 更新DE 翻译
* 启用通知管理代表团
* 操作电子邮件批准请求:示例电子邮件操作的默认发件人
* 解决办法:批准提示在编辑模式:双弹出
* 从reply_to可以指定为操作电子邮件批准请求的对象(只有approval_base模块中设置)
*增强的SLA计算中的新方法,以减轻可扩展性
* 时间强制覆盖窗口中打开
2019-03-261.4.5* 修复:编辑模式的审批提醒 : 两次弹出
2018-12-131.4.4

* 修复西班牙翻译文件编码
* 将缺少的调和键添加到ApprovalScheme类
* 将缺少的调和键添加到ExtendedApprovalScheme类
* 修复审批表单的UI小故障
* 提示jQuery兼容性 (从iTop 2.6起jQuery 3)

2018-06-271.4.3德语翻译更新
2018-06-261.4.2

- 新翻译(西班牙,巴西)和修复审批请求触发器的CSV导入

-修复等待批准的对象不在用户范围内时门户中附件不可用(的缺陷)。

2018-01-261.4.1

Bug修复:如果未选择增强门户,则无法安装扩展

2017-11-141.4.0需要iTop 2.3.0:将审批管理纳入增强型门户
2017-11-141.3.5修复2个周期之间混合的批准工具提示
2017-09-271.3.4与iTop 2.4门户的兼容性修复
2017-09-011.3.3日志中记录的注释:运营商退货退回 - 在门户摘要页面选中/取消选中全部 -如果第1级没有批准人,请勿跳过级别2 - 缺少索引,减缓票证显示速度 - 解码后的菜单组“ 帮助台“的位置 - 修复从具有与iTop时区不同的时区的浏览器进行编辑时修复损坏的覆盖窗口
2016-11-301.3.2通过触发器/操作的均值配置的电子邮件 - 使用HTML占位符的电子邮件/表单模板(正确转义的HTML实体) - 菜单组“帮助台”不能通过XML增量
2016-08-091.2.1基于XML的实现为了减少一些定制 - 包括一个支持增强型客户门户中的审批的库(需要进一步的自定义)
2016-07-111.2.0现在需要iTop 2.2.0! - 错误修复:尝试批准时,“门户用户”重定向到客户门户 - 格式正确的日期和时间(如果iTop版本> = 2.3.0) - 在创建票证页面上隐藏快捷按钮(分配) 是DB中的一些批准规则 - 在日历中拖放时间间隔时防止间隔溢出到第二天
2015-09-301.1.3禁用标准属性用户请求 :: approver_id和approver_email,因为它们在安装此模块时没有意义。 从Approval Rule版本表单中删除“plus”按钮,以解决覆盖窗口创建窗体中的错误(当显示为对话框时,需要修复iTop的核心,与组件“SLA With Coverage Windows”版本 > = 2.1.0,或者模块“combodo-coverage-windows-computation> = 2.0.0)
2014-12-181.1.2手动发送提醒; 在同一张工单上支持多次执行(与此版本之前记录的数据追溯工作); 即使评论留空(在绕过流程时已经完成),也可以在日志中记录一些内容; 如果批准者已经给出答案,则批准/拒绝菜单必须隐藏; 如果用户绕过流程,并且她的账户有定义的联系人,则用户的标识符(显示在新日志条目的标题中)必须是联系人友好的名称(不是用户登录名)。 将误导性消息“现在完成并失败”更改为“现在完成,结果为拒绝”; 防止CRON每分钟创建一个CMDB变更记录; 修正法语字典中的拼写错误; 更改了模块名称(内部)
2014-04-241.0.3当电子邮件地址错误或丢失时更好的错误报告。 特别是刚刚安装模块时,配置条目sender_email保留为空,并且当电子邮件传输为SMTP时会产生可怕的错误消息
2014-03-071.0.2整合德文翻译(感谢ITOMIG GmbH)
2014-03-051.0.1第一个版本(修复发现原型的bug:无论批准规则中的设置如何,始终批准超时)

要求

至少iTop 2.4.0

安装

使用标准的安装流程

配置

安装此模块后,请配置正确的email_sender并配置触发器/操作以确保交付“批准eMails”。

以下设置可用于配置模块:

模块参数属性说明默认值
approval-base

email_sender

发件人电子邮件地址,在批准电子邮件中所示。 如果留空,发送电子邮件将失败。 
approval-base

email_reply_to

默认的“回复”电子邮件地址以获得批准电子邮件。

(可选)默认为email_sender

approval-base

comment_attcode

将报告用户评论的属性。 可以是案例日志或文本。 评论全部汇总。 注意:评论也可以被视为工具提示。(可选)
approval-base

list_last_first

布尔在发生多次执行的情况下,驱动显示执行结果的顺序(垂直)。false
approval-base

enable_reminder

布尔启用“发送提醒”功能。true
approval-extended

enable-admin-abor

布尔允许定义的配置文件绕过审批流程。 允许绕过流程的配置文件在变量bypass_profiles中定义。true
approval-extended

target_state

状态可能会触发审批流程false
approval-extended

bypass_profiles

配置文件的CSV列表。 有任何给定的配置文件足以被允许绕过审批流程。 设置为空字符串以拒绝任何人的功能。

管理员/服务管理者

approval-extended

reuse_previous_answers

布尔如果一个人在两个级别都是批准者,那么他的第1级决定会在第2级重用true

设置审批功能时,以下标准设置可能会引起您的兴趣:

email_asynchronous

email_transport

通知(触发器/操作)

电子邮件通知基于触发/操作,电子邮件内容可以根据您的需求使用HTML格式和占位符进行量身定制。

安装时会创建一个默认触发器

https://www.itophub.io/wiki/media?w=400&tok=bb849c&media=extensions%3Aapprovaltrigger.png

以及英文,法文和德文的3种默认操作。

https://www.itophub.io/wiki/media?w=400&tok=84e14a&media=extensions%3Aapprovalnotif.png

你当然可以编辑这条消息使它成为你自己的,这里是可能是英文默认版本的占位符例子:

尊敬的$ approver→html(friendlyname)$,

请花一些时间批准或拒绝工单$ this→html(ref)$

调用者:$ this→html(caller_id_friendlyname)$

标题:$ this→html(title)$

服务:$ this→html(service_name)$

服务子类别:$ this→html(servicesubcategory_name)$

描述:

$this→HTML(介绍)$

附加信息:

$this→HTML(service_details)$

$ approval_link$

https://www.itophub.io/wiki/media?w=400&tok=17f54b&media=extensions%3Aapprovaldefaultnotif.png

您必须创建您要使用的语言的触发器和动作之间的链接。

https://www.itophub.io/wiki/media?w=400&tok=509268&media=extensions%3Aapprovaltriggeredit3.png

您可以创建自己的触发器和操作

如果您需要发送不同的通知,具体取决于调用者的组织,服务,服务族或任何可用的工单数据,可以通过在触发器上使用过滤器创建多个触发/操作对来完成。

用户经验

流程

当用户请求进入新的状态时,审批引擎将验证是否存在为相应的服务子类别定义的审批规则。如果是,则将用户请求的状态设置为等待批准,并将通知发送给批准规则中定义的批准者。仅通知与第一级相对应的审批者。一旦请求被批准,并且如果已经定义了第二级,则通知第二级批准者。如果批准被批准(由批准者或超时)拒绝,则该过程在任何情况下结束。

该电子邮件包含一个Web链接,用于显示该网页以批准或拒绝该请求。

批准者在批准规则中会有一个延迟,以给出他们的答案。此延迟考虑了批准规则中定义的覆盖范围窗口。

审批延迟一旦过期,审批流程即告终止。如果在批准规则的1/2级别上没有答案,则结果(批准或拒绝)将被置于自动批准的属性中。

然后,用户请求将在其生命周期中继续执行,具体取决于审批状态:拒绝或批准。

创建审批规则

从服务管理菜单中,单击批准规则:

https://www.itophub.io/wiki/media?w=200&tok=629a6a&media=extensions%3Acombodo-approval-extended-menu.png

这些页面显示了已定义的批准规则的列表。 点击“新建”按钮创建一个新的规则:

https://www.itophub.io/wiki/media?w=900&tok=458e67&media=extensions%3Acombodo-approval-extended-create-noplus.png

批准规则是其名称的标识符。 覆盖窗口用于计算审批延迟。

字段审批级别1和2通过OQL查询定义每个审批级别的审批者列表。 这些查询必须返回具有电子邮件属性的元素(例如个人或团队)。 可以使用占位符:this-> attribute来引用用户请求的属性。

例如:this-> caller_id用于调用者,:this-> service_id用于服务...可以使用数据模型中为服务请求定义的所有属性。

已知限制:必须允许创建用户请求的用户查看批准者,否则用户请求将保持新状态。

如果请求方允许组织,但批准者不属于其中一个组织,则会发生此问题

如果在定义的延迟后没有应答,则如果没有答案确定请求将被批准或拒绝,则自动批准字段。

现场批准延迟(小时)定义每个批准等级的延迟时间,只有覆盖范围内的小时数被计入..

现场批准结束对于多个批准者来说很有用,以确定如何采取多种行动:

1、首个批准结束:所有必须拒绝请求被拒绝。

  • 多个拒绝,然后一个批准⇒结束和批准
  • 多个拒绝,但不是全部然后延迟过期⇒结束和“拒绝或批准”取决于领域自动批准,如果没有应答

2、结束于第一次拒绝先前的默认行为:所有必须批准。

  • 多个批准,然后一个拒绝⇒结束并拒绝
  • 多个批准,但不是全部然后延迟到期⇒结束

3、第一个答复结束=首先行动是决策者。

一旦定义了批准规则,您可以从批准规则本身(选项卡服务子类别)或服务子类别中将其分配给服务子类别:

https://www.itophub.io/wiki/media?media=extensions%3Acombodo-approval-extended-servicesubcategory.png

审批流程

持有iTop登录信息的审批人可以随时进行连接,并检查他们是否有申请待批准。 从帮助台菜单中,单击正在进行的审批:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval-menu.png

该页面显示正在运行审批流程的用户请求列表,并且您正在请求审批:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval-monitoring.png

没有iTop登录的审批者仍然可以批准或拒绝请求,但他们必须已收到此通知。 电子邮件提供的链接允许他在没有iTop登录的情况下批准或拒绝。

没有iTop登录的审批者,给予电子邮件授权,同时给予iTop批准授权

如果批准者有iTop登录,那么通过电子邮件提供的链接将他指向iTop(控制台或门户,取决于他的访问权限)。 在这种情况下,电子邮件中提供的链接只能与批准者iTop登录一起使用。

批准或拒绝

从用户请求中,打开其他操作菜单并选择批准或拒绝:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_menu_reply.png

显示审批表单:

https://www.itophub.io/wiki/media?w=600&tok=205bb9&media=extensions%3Aapproval_reply.png

答复完成后,您将被重定向到用户请求,并且横幅条会提醒您答复的结果。

https://www.itophub.io/wiki/media?w=600&tok=f3f290&media=extensions%3Aapproval_back.png

绕开审批流程

如果您是管理员,并且安装程序允许,则您有一个菜单可通过该过程:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_menu_bypass.png

审批表格与标准答复表格稍有不同:它提醒您通过该过程有一点不同。

https://www.itophub.io/wiki/media?w=600&tok=38e99d&media=extensions%3Aapproval_bypass.png

https://www.itophub.io/bundles/combododokuwiki/img/note.png如果您既是批准者又允许通过流程,那么这两个菜单都是允许的。 使用其中一种方法只会改变审批流程结果的记录方式,并进一步显示在状态标签中。

状态

只要用户请求通过审批流程,标签审批状态就会显示有关正在进行或终止审批的详细信息。

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_status_ongoing.png

在上面的例子中,截止日期以粗体显示:1月21日12:47。

点击“发送提醒”按钮向审批者发送新消息(需要确认)。 可以通过将参数enable_reminder设置为false来禁用此功能。

答复完成后,状态显示为明确:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_status_rejected.png

将鼠标移到审批者姓名旁边的图片上,如果有答案,您将得到答案的日期和她的评论:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_status_comment.png

只要用户请求进入“等待批准”状态,状态就会完全复位。

门户网站审批

增强型门户中会出现一个新菜单,允许审批者检索所有等待她批准的用户请求,并逐个或以批量模式接受或拒绝它们。

https://www.itophub.io/wiki/media?w=600&tok=10bb58&media=extensions%3Aapprovalportal.png

如果拒绝,则需要评论,所以只要评论为空,该按钮就被禁用。 两种情况都需要确认。

https://www.itophub.io/wiki/media?w=600&tok=ec0a4c&media=extensions%3Aapprovalportalconfirmation.png

点击用户请求链接时,工单的详细信息会显示一个额外的注释字段和详细信息底部的两个按钮,以接受或拒绝该信息:

https://www.itophub.io/wiki/media?w=600&tok=e71d4c&media=extensions%3Aapprovalportalonerequest.png

问题与解答

题:如果批准规则在所有批准级别上返回零批准者,会发生什么?
回答:该请求永远不会进入批准周期。

题:在给定的延迟后,如何自动向提醒者发送提醒?
回答:今天没有简单的方法可以做到这一点。

在要批准的对象类上添加请求的日期字段批准,比如工单。

当工单进入等待批准的状态时,在转换上使用now()设置批准要求的开启日期。

创建一个每日后台任务,由于确切的延迟* n天,它会在等待批准的情况下检索工单,并发送提醒(假设有一个可访问的PHP职能至触发器此提醒FIXME)→延迟= 7这将使触发器每次提醒只要不批准七天。

原贴链接:https://www.itophub.io/wiki/page?id=extensions%3Aapproval_extended


Approval process automation

name:
Approval process automation
description:
Control your approval process with predefined rules based on service catalog
version:
2.0.1
release:
2020-03-18
itop-version-min:
2.4.0
code:
combodo-approval-process-automation
state:
stable
alternate-name:
Approval Extended
diffusion:
iTop Hub

For iTop versions older than 2.2.0 use 1.1.3.
For iTop 2.2.x or 2.3.x, use 1.2.2 or better 1.3.5
For iTop 2.4.0 or higher, use this version or above

Other versions of this component: 1.1.31.2.21.3.5

This module provides the capability to handle a two levels approval process for a user request, with several approvers in parallel on each level.

Features

  • Automated, rule based, approval mechanism.

  • Supports passive or active approval and configurable timeout delay.

  • Two levels of approbation with several approvers in parallel at each level.

  • Approvers can approve or reject a request in one click from an email (no need to have an iTop account) or multiple requests pending for their approval in Console or Portal.

  • Graphical view of the approval status on each ticket.

  • Configurable approval email message, with multi-language capabilities.

Revision history

DateVersionDescription
2020-03-182.0.1* Bring compatibility with iTop 2.7
* Fix TWIG template not found when trying to open object form
2020-03-052.0.0* Add compatibility with iTop 2.7+
* Update DE translations
* Enable Notification management delegation
* ActionEmailApprovalRequest : default sender for sample email actions
* Fix: Approval reminder in edit mode : double pop-up
* from and reply_to can be specified in ActionEmailApprovalRequest objects (were only available in approval_base module settings)
* New methods in EnhancedSLAComputation to ease extensibility
* Open Hours mandatory for Coverage Window
2019-03-261.4.5* Fix: Approval reminder in edit mode : double pop-up
2018-12-131.4.4* Fix spanish translation files encoding
* Add missing reconciliation key to the ApprovalScheme class
* Add missing reconciliation key to the ExtendedApprovalScheme class
* Fix UI glitch on approval form
* Improve jQuery compatibility (jQuery 3 since iTop 2.6)
2018-06-271.4.3DE translation update
2018-06-261.4.2- New translations (ES, BR) and fix CSV import of TriggerOnApprovalRequest.
- Fix attachments unavailable in portal when object waiting for approval was not within user's scopes.
2018-01-261.4.1Bug fix: Extension could not be installed if Enhanced Portal was not selected.
2017-11-141.4.0Requires 2.4.0 or higher: Approval in Enhanced Portal
2017-11-141.3.5Bug fix: Tooltips not showing for all comments when several answers of the same user (Typically rejected then accepted an user request)
2017-09-271.3.4fix 2.4 compatibility issue
2017-09-011.3.3- Comments recorded in the log: loosing carriage returns
- Fix Check/Uncheck All on portal summary page
- Do not skip level 2 if there is no approver on level 1
- Missing index, slowing down the display of a ticket
- dishardcoded menu group “Helpdesk” position
- Fix corrupted coverage windows when edited from a browser having a timezone different from the timezone of iTop
2016-11-301.3.2Approval Emails configurable by the mean of triggers/actions with placeholders - Select the step ending condition in each step of the approval rule - Do not ask several times an approval to the same person
2016-08-091.2.1- XML-based implementation in order to ease some customizations - include a library for the support of approvals in the enhanced customer portal (requires further customizations though)
2016-07-111.2.0Now requires iTop 2.2.0! - Bug fix: “Portal users” redirected to the customer portal when trying to approve - Date and time correctly formatted (if iTop version >= 2.3.0) - Hide the shortcut buttons (Assign) on the ticket creation page, ONLY IF there are some approval rules in the DB - Prevent overflow of interval to the next day when dragging/dropping intervals in the calendar
2015-09-301.1.3Disable the standard attributes UserRequest::approver_id and approver_email, as they do not make sense when this module is installed. Removed the “plus” button from the Approval Rule edition form, to workaround a bug in the coverage windows creation form (when shown as a dialog, requires a fix in the core of iTop, related to the component “SLA With Coverage Windows” version >=2.1.0, or the module “combodo-coverage-windows-computation>=2.0.0)
2014-12-181.1.2Manually send a reminder ; Support of several executions on the same ticket (works retroactively with data recorded prior to this version) ; Record something into the log even if the comment is left empty (was already done when bypassing the process) ; If an approver already gave her answer the approve/reject menus must be hidden ; If a user bypasses the process, and if her account has a contact defined, then the identifier of the user (shown in the header of the new log entry) must be the contact friendly name (not the user login) ; Changed the misleading message “is now complete with failure” into “is now complete with result REJECTED” ; Prevent the CRON from creating one CMDBChange record per minute ; Fixed typos in the french dictionary ; Changed the module name (internal)
2014-04-241.0.3Better error reporting when an email address is wrong or missing. In particular when the module has just been installed, the configuration entry sender_email is left empty and this produces a scary error message when the email transport is SMTP
2014-03-071.0.2Integration of the German translation (thanks to ITOMIG GmbH)
2014-03-051.0.1First release (fixes a bug found the prototype: always approve on timeout, whatever the setting in the approval rule)

Requirements

  • Requires at least iTop 2.4.0.

  • cron.php must be running to enable processing of approval timeout.

Installation

Use the Standard installation process for this extension.

Configuration

After installing this module, configure a proper email_sender and configure trigger/action to ensure “Approval eMails” delivery.

The following settings are available to configure the module:

ModuleParameterTypeDescriptionDefault Value
approval-baseemail_senderstringSender eMail address, as seen in the approval email. If left blank, sending the email will fail. 
approval-baseemail_reply_tostringDefault “reply to” eMail address for the approval email. If empty defaults to email_sender 
approval-basecomment_attcodestringAttribute into which the user comments will be reported. Can be a case log or text. The comments are all aggregated. Note: the comment can also be viewed as a tooltip.(optional)
approval-baselist_last_firstbooleanIn case several executions occur, drives the order in which the results of the executions are displayed (vertically).false
approval-baseenable_reminderbooleanEnable the feature “send a reminder”.true
approval-extendedenable-admin-abortbooleanAllow defined profiles to bypass the approval process. Profiles allowed to bypass the process are defined in the variable bypass_profiles.true
approval-extendedtarget_statestringstate that may trigger the approval process. The event ev_wait_for_approval must exist on this state, ending on wait_for_approval state.new
approval-extendedbypass_profilesstringCSV list of profiles. Having any of the given profiles is sufficient to be allowed to bypass approval processes. Set to an empty string to deny the feature to anybody.Administrator, Service Manager
approval-extendedreuse_previous_answersbooleanIf a person is approver at both level then his level 1 decision is reused at level 2true

The following standard settings might be of interest when setting up the approval feature:

  • email_asynchronous

  • email_transport

Notification (trigger/action)

Email notification is based on Trigger/Action and email content can be tailored to your need with HTML format and placeholders.

A default trigger is created at installationhttps://www.itophub.io/wiki/media?w=400&tok=bb849c&media=extensions%3Aapprovaltrigger.pngas well as 3 default actions with body in English, French and German.https://www.itophub.io/wiki/media?w=400&tok=84e14a&media=extensions%3Aapprovalnotif.png

You can of course edit this message to make it yours, here is the english default version for example of possible placeholders:

Dear $approver→html(friendlyname)$,
Please take some time to approve or reject ticket $this→html(ref)$

Caller: $this→html(caller_id_friendlyname)$
Title: $this→html(title)$
Service: $this→html(service_name)$
Service subcategory: $this→html(servicesubcategory_name)$

Description:
$this→html(description)$

Additional information:
$this→html(service_details)$

$approval_link$

https://www.itophub.io/wiki/media?w=400&tok=17f54b&media=extensions%3Aapprovaldefaultnotif.pngYou must create the linkage between trigger and action of the language you want to use.https://www.itophub.io/wiki/media?w=400&tok=509268&media=extensions%3Aapprovaltriggeredit3.png

You can create your own trigger and action
If you need to send different notification depending on the organization of the caller, the service, the service family, or any data available on the Ticket, this can be done by creating multiple trigger/action couples, using a filter on the Trigger.

User experience

Cinematics

When a User Request is entering the state new, the approval engine verifies if there is an approval rule defined for the corresponding service subcategory. If yes, then the state of the user request is set to wait for approval and a notification is sent to the approvers defined in the approval rule. Only the approvers corresponding to the first level are notified. Once the request is approved, and if a second level has been defined, then the second level approvers are notified. Should the approval be rejected (by an approver, or on timeout), then the process finishes in any case.

The email contains a web link to display the web page to approve or reject the request.

The approvers will have a delay defined in the approval rule to give their answers. This delay takes into account the coverage window defined in the approval rule.

Once the approval delay has expired, the approval process terminates. The result (approved or rejected) is then taken in the property Automatically approved if no answer at Level 1/2 of the approval rule.

The User Request will then continue its way through its lifecycle, depending on the approval status: rejected or approved.

Create approval rules

From the Service Management menu, click on Approval rules:https://www.itophub.io/wiki/media?w=200&tok=629a6a&media=extensions%3Acombodo-approval-extended-menu.png

The pages show a list of already defined approval rules. Click on the button “new” to create a new one:

https://www.itophub.io/wiki/media?media=extensions%3Aapprovalruleedit.png

An approval rule is identifier by it name. The coverage window is used to compute the approval delay.

The fields Approval level 1 and 2 define, via an OQL query, the list of approvers for each approval level. These queries must return elements having an email attribute (e.g. Person or Team). It is possible to use the place holders :this->attribute that make reference to the attributes of the user request.

For instance :this->caller_id for the caller, :this->service_id for the service … All attributes defined in the data model for a service request can be used.

Known limitation: The user creating the user request must be allowed to see the approvers, otherwise the User Request stays in New status.
The issue will occur if the Requestor has allowed organizations but the approver does not belong to one of those organizations

The field Automatically approved if no answer determines if the request will be approved or rejected if there is no answer after the defined delay.

The field approval delay (hours) defines the delay in hours for each level of approval, only hours within the coverage windows are counted..

The field approval ending is useful with multiple approvers to determine, how to behave with multiple actions:

  1. ends on first approve : All must reject for Request to be rejected.

    •  

    Multiple rejected then one approved ⇒ ends and approved

    •  

    multiple rejects but not all then delay expired ⇒ ends and “reject or approved” depends on field Automatically approved if no answer

  2. ends on first reject previous default behavior: all must approved.

    •  

    Multiple approval then one reject ⇒ ends and reject

    •  

    multiple approvals but not all then delay expired ⇒ ends and “reject or approved” depends on field Automatically approved if no answer

  3. ends on first reply = first to act is the decision maker.

Once the approval rule has been defined, you can assign it to a service subcategory, either from the approval rule itself (tab Service subcategory) or from the service subcategory:

https://www.itophub.io/wiki/media?media=extensions%3Acombodo-approval-extended-servicesubcategory.png

Approving process

Approver with an iTop login can connect anytime and check if they have Requests pending their approval. From the Helpdesk menu, click on Ongoing approvals:https://www.itophub.io/wiki/media?media=extensions%3Aapproval-menu.png

The page shows a list of the User Requests having an approval process running, and for which your approval is being requested:https://www.itophub.io/wiki/media?media=extensions%3Aapproval-monitoring.png

Approver without iTop login, can still approve or reject Request, but they must have received the notification for this. The email provided link allows him to approve or reject without iTop login.

Approver without iTop login, giving email delegation, give at the same time iTop approval delegation

If the approver has an iTop login then the email provided link points him to iTop (Console or Portal depending on his access). In that case, the link provided in the email can only be used with the approver iTop login.

Approve or reject

From the user request, open the Other actions menu and select Approve or Reject:https://www.itophub.io/wiki/media?media=extensions%3Aapproval_menu_reply.png

The approval form is displayed:https://www.itophub.io/wiki/media?w=600&tok=205bb9&media=extensions%3Aapproval_reply.png

After the reply has been given, you are redirected to the user request and a banner reminds you the outcome of your reply.https://www.itophub.io/wiki/media?w=600&tok=f3f290&media=extensions%3Aapproval_back.png

Bypass the approval process

If you are an administrator, and if the setup allows it, then you have a menu to bypass the process:https://www.itophub.io/wiki/media?media=extensions%3Aapproval_menu_bypass.png

The approval form is then a little different than the standard reply form: it reminds you that bypassing the process is a little different.

https://www.itophub.io/wiki/media?w=600&tok=38e99d&media=extensions%3Aapproval_bypass.png

If you are both an approver and allowed to bypass the process, then both menus are allowed. Using one or the other will just change the way the approval process result gets recorded and further displayed in the status tab.

Status

As soon as a user request has been through an approval process, the tab Approval status shows detailed information about the ongoing or terminated approval.

Ongoing approval

In the above example, the deadline is displayed in bold: 21st of january at 12:47.

Click on the button “send a reminder” to send a new message to the approver (confirmation required). This feature can be disabled by setting the parameter enable_reminder to false.

After the reply has been given, the status appears in clear:

Rejected approval

Move your mouse over the image next to the approver's name, and you will get the date of the answer and her comment if any has been given:

https://www.itophub.io/wiki/media?media=extensions%3Aapproval_status_comment.png

The status will be entirely reset anytime the user request enters the state “waiting for approval”.

Approval in portals

A new menu appears in the Enhanced Portal, which allow an approver to retrieve all User Requests waiting for her approval, and one by one or in bulk mode, accept or reject them.https://www.itophub.io/wiki/media?w=600&tok=10bb58&media=extensions%3Aapprovalportal.png

A comment is required in case of rejection, so the button is disabled as long as the comment is empty. A confirmation is required in both cases.https://www.itophub.io/wiki/media?w=600&tok=ec0a4c&media=extensions%3Aapprovalportalconfirmation.png

When clicking on the link to a User Request, the ticket's details are displayed with an extra comment field and two buttons at the bottom of the details to accept or reject it:https://www.itophub.io/wiki/media?w=600&tok=e71d4c&media=extensions%3Aapprovalportalonerequest.png

Question & Answers

Question: What happen if the approval rule returns zero approvers, on all level of approval?
Answer: The request is never entering the approval cycle.

Question: How to automatically send a reminder to Approvers after a given delay?
Answer: There is no easy way to do this today.

  • add a date field approval-requested-on on the to be approved object class, let say a Ticket.

  • When the Ticket enter the state waiting for approval, on the transition set the approval-requested-on date with now().

  • Create a daily background task, which retrieve Ticket in waiting on approval, since exactly delay*n days, and send a reminder (assuming there is an accessible PHP function to trigger this reminder FIXME) → with delay = 7 this would trigger a reminder every seven days as long as not approved.

标签:
由 superadmin 在 2020/08/25, 16:39 创建
    

需要帮助?

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

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