管理工作流程

工作流由 Jira 管理控制台集中控制和管理，因此您需要成为管理员才能创建和配置工作流。要管理工作流程，请执行以下步骤：

以 Jira 管理员身份登录 Jira。
浏览至 Jira 管理控制台。
选择问题选项卡，然后选择 工作流程 选项。这将打开 查看工作流程 页面：

Figure 1. Figure 7.3 – Workflow list page

在 查看工作流程 页面，您可以管理所有可用的工作流程并创建新的工作流程。该页面分为两个部分：活动和 非活动。激活的工作流程正在被项目使用，而非激活的工作流程没有被项目使用。默认情况下，非活动 部分是折叠的，因此页面只显示活动工作流。前面的截图显示两个部分都展开了。

Jira 自带一个名为 jira 的默认只读工作流，主要用于与现有项目保持向后兼容，该工作流适用于未应用任何特定工作流的项目。因此，您不能编辑或删除此工作流程。新项目将根据所选模板创建自己的工作流程。这些特定于项目的工作流程名称将以项目关键字开头，然后是项目模板，如 HR: Task Management Workflow。

问题状态

在 Jira 工作流中，问题状态代表问题在工作流中的一种状态。它描述了问题的当前状态。如果把它比作流程图，突出显示的矩形表示问题在流程中的当前状态。就像一个任务只能处于业务流程的一个阶段一样，一个问题在任何时候都只能处于一种状态；例如，一个问题不能同时处于打开和关闭状态。

还有一个术语叫步骤，它是状态的工作流术语。由于 Jira 简化了工作流管理，步骤和状态可以互换使用。为了保持一致，除非在特殊情况下需要区分，否则我们将在本书中使用状态一词。

过渡

状态代表工作流程中的各个阶段，而将问题从一个状态带到下一个状态的路径称为过渡。过渡将两个状态连接在一起。过渡状态不能独立存在，这意味着它必须有开始和结束状态，而且每种状态只能有一个。这意味着过渡不能有条件地分离到不同的目标状态。过渡也只能是单向的。这意味着，如果一个转场将一个问题从状态 A 带到状态 B，那么如果想从状态 B 回到状态 A，就必须创建一个新的转场。

过渡有几个组成部分。在此列出：

条件：在用户可以执行转换（可见）之前，必须满足条件。这些条件通常用于控制用户执行转换的权限。
验证器：在执行转换之前必须通过的验证。它们通常与过渡屏幕一起使用。
后期功能：这些是作为过渡流程的一部分执行的附加功能。
过渡屏幕：这是用户执行转换时显示的可选屏幕。它通常用于捕捉过渡过程中的附加信息。
触发器：如果您已将 Jira 与 Bitbucket 或 GitHub 等其它开发工具集成，触发器可在事件发生时自动执行转换，例如创建新分支或有人提交代码时。

一个常见的技巧是创建一个可以链接回自身的过渡。由于转场可以拥有自己的屏幕，并通过后置函数执行一些业务逻辑，因此您可以将这种转场用作 用户界面（UI） 中的触发器，以显示屏幕或运行后置函数，而无需进行复杂的定制。

前三个组件中的每一个都定义了转场的行为，使您可以执行前置和后置验证，以及转场执行后的处理。我们将在下面的章节中深入讨论这些组件。

触发器

如前所述，在开始使用触发器之前，Jira 需要与以下系统之一集成：

Atlassian Bitbucket
Atlassian FishEye/Crucible
GitHub

触发器将监听来自集成开发工具的更改，如代码提交，当这些更改发生时，触发器将自动执行工作流转换。请注意，发生这种情况时，所有权限都会被忽略。

条件

有时，您可能希望控制谁可以执行转换或何时可以执行转换。例如，授权问题的转换应仅限于经理组的用户，这样普通员工就无法授权自己的请求。这就是条件的作用。

条件是允许用户执行转换之前必须满足的标准。如果不满足过渡的条件，用户在查看问题时将无法使用过渡。下表显示了 Jira 附带的条件列表；其它条件可通过第三方附加组件添加：

Table 1. Table 7.1 – Workflow conditions
条件	描述
Code Committed Condition	仅当代码已经/尚未（取决于配置）针对此问题提交时，这才允许执行转换。
Hide Transition from User	这将对所有用户隐藏转换，并且只能由后期功能触发。这在转换作为自动化过程的一部分而不是由用户手动触发的情况下非常有用。
No Open Reviews Condition	这允许仅在没有相关的情况下才执行转换打开坩埚评论。
Only Assignee Condition	这仅允许问题的当前受让人执行转换。
Only Reporter Condition	这仅允许问题报告者执行转换。
Permission Condition	这仅允许具有给定权限的用户执行转换。
Sub-Task Blocking Condition	这会根据所有子任务的状态阻止父问题转换。
Unreviewed Code Condition	仅当不存在与此问题相关的未查看的变更集时，才允许执行转换。
User Is In Group	这仅允许给定组中的用户执行转换。
User Is In Group Custom Field	这仅允许给定组自定义字段中的用户执行转换。
User Is In Project Role	这仅允许给定项目角色中的用户执行转换。

验证器

验证器与条件类似，但它们会在允许完成转换之前验证某些标准。条件会在不满足条件时向用户隐藏工作流转换，而验证器会允许用户看到转换，但如果不满足条件，则不允许执行转换。

验证器最常见的用例是在过渡期间验证用户输入。例如，可以验证用户是否为工作流屏幕上显示的所有字段输入了数据。下表显示了 Jira 随附的验证器列表；其它验证器可通过第三方附加组件添加：

Table 2. Table 7.2 – Workflow validators
验证器	描述
Permission Validator	这将验证用户是否具有所选权限。当检查执行转换的人员是否具有所需的权限时，这非常有用。
User Permission Validator	这验证用户是否具有选定的权限，其中保存用户名的 OSWorkflow 变量是可配置的。这已经过时了。

后置函数

顾名思义，后置函数是在执行转换后发生的函数。这样，您就可以在执行转换后执行其它流程。Jira 在内部大量使用后置函数来执行很多功能。例如，当您转换一个问题时，Jira 会使用后置函数更新其搜索索引，这样您的搜索结果就会反映问题状态的变化。

如果过渡执行失败（例如，验证器验证失败），则不会触发过渡附加的后置函数。下表显示了 Jira 随附的发布函数列表，其它发布函数可通过第三方附加组件添加：

Table 3. Table 7.3 – Workflow post functions
后置函数	描述
Assign to Current User	如果当前用户具有可分配的用户权限，这会将问题分配给当前用户。
Assign to Lead Developer	这会将问题分配给项目/组件首席开发人员。
Assign to Reporter	这将问题分配给记者。
Create Perforce Job Function	这将在完成工作流转换后创建一个 Perforce 作业（如果需要）。
Notify HipChat	这会向一个或多个 HipChat 房间发送通知。
Trigger a Webhook	如果执行此发布函数，Jira 会将 JavaScript 对象表示法 (JSON) 格式的问题内容发布到指定的统一资源定位器 (URL)。
Update Issue Field	这会将系统字段（例如摘要）更新为给定值。

我们已经了解了工作流程的所有主要组成部分。下一节，我们将了解如何使用工作流程设计器工具设计工作流程。