Issue
Issue的创建方式
Issue的生命周期是从它被创建的一刻开始的。创建Issue的方法一般有以下几种：
- MantisBT的Web界面——也就是用户登录MantisBT后报告Issue的地方。
- SOAP API——应用可以通过SOAP API自动地往MantisBT创建Issue。例如，夜间脚本可以自动监测build失败的地方并自动上报。
- Email——此方法不支持开箱即用，但现有的MantisBT补丁可以监听预先配置的电子邮件地址，并将其上报的Issue添加到MantisBT数据库中
- 其他——还有两种其他方式来报告问题：直接向MantisBT数据库创建Issue的应用程序/脚本（不推荐，一次性迁移脚本除外），使用MantisBT core API创建Issue的PHP脚本。
Issue的状态
通过issues的状态而将他们进行区分是issue追踪中较为重要的一环。每个开发团队可能都会有一套自己的issue状态定义，于是MantisBT提供了自定义issue status的功能。MantisBT认为一个issue可以被分为三个状态：Opened，Resolved和Closed。至此，所有的自定义status都会被映射到这三个状态上。比如MantisBT内置了以下几个状态： new, feedback, acknowledged, confirmed, assigned, resolved 和 closed。在这个例子中，new->assign会被映射到opened，resolved即resolved，closed即closed
以下是对MantisBT所提供的内置标准状态的解释：
-
New——这是新Issue的初始状态。问题在被
assigned、acknowledged、confirmed或resolved之前，一直处于这种状态。下一个状态可以是assigned、acknowledged、confirmed或resolved。 -
Acknowledged——这个状态是由开发团队用来反映他们对Issue"请求"的同意。或者同意报告人在问题报告中的建议，尽管他们还没有尝试重现报告人所指的内容。下一个状态通常是
assigned或confirmed。 -
Confirmed——这个状态通常被开发团队用来提及他们同意报告者在问题中的建议，并且他们已经确认并重现了这个问题。下一个状态通常是
assigned。 -
Assigned——这个状态用来反映这个问题已经被分配给某个团队成员，并且这个团队成员正在积极处理这个问题。下一个状态通常是
resolved。 -
Resolved——这个状态用来反映问题已经被解决。一个问题可以用许多最终status之一来解决（可自己修改）。例如，一个问题可以被解决为
fixed,duplicate,won't fix,no change required, etc. 下一个状态通常是closed或者feedback -
Closed——这个状态反映了问题已经完全关闭，不需要进一步的行动了。它通常也会将问题从 "查看问题 "页面隐藏起来。一些团队使用
closed来反映报告人，另一些团队使用它来反映修复已经发布给客户的事实。
工作流
现在我们已经介绍了issue是如何被创建的，以及在这些issue的生命周期内有哪些不同的状态，下一步是定义工作流。工作流规定了Issue状态之间的有效转换，以及触发这种转换的用户所需的角色；换句话说，issue如何从一个状态转移到另一个状态，以及谁有权触发这种转换。
MantisBT为团队提供了定义他们自己的自定义工作流，该工作流在他们的自定义状态之上运行（见 "Customizing Status Values "的部分）。
工作流转换
一般情况下，如果没有定义工作流，这意味着所有的状态都可以从任何其他地方被任何人访问。
在 "Manage > Configuration> Workflow Transition"页面，具有ADMINISTRATOR访问级别的用户可以完成以下任务:
- 定义每个状态的有效下一个状态
- 定义每个状态的默认下一个状态
- 定义用户过渡到每个状态所需的角色。
- 定义新创建问题的默认状态
- 定义问题被认为已经解决的状态。任何状态代码大于或等于指定状态的问题都将被视为已解决。
- 定义分配给重新开放的问题的状态。
- 定义改变工作流程所需角色。
注意，应用的所影响的范围取决于所选的项目。如果选择了 "所有项目"，那么该配置将作为所有项目的默认配置，除非被特定的项目覆盖。要为一个特定的项目进行配置，通过屏幕右上角的组合框切换到该项目。
全局（"All Projects"）的工作流也可以在config_inc.php文件中定义，如下所示
$g_status_enum_workflow[NEW_] ='30:acknowledged,20:feedback,40:confirmed...官方文档后面没了
$g_status_enum_workflow[FEEDBACK] ='30:acknowledged,40:confirmed,50:assigned...官方文档后面没了
$g_status_enum_workflow[ACKNOWLEDGED] ='40:confirmed,20:feedback,50:assigned,80:r...官方文档后面没了
$g_status_enum_workflow[CONFIRMED] ='50:assigned,20:feedback,30:acknowledged,8...官方文档后面没了
$g_status_enum_workflow[ASSIGNED] ='80:resolved,20:feedback,30:acknowledged,4...官方文档后面没了
$g_status_enum_workflow[RESOLVED] ='90:closed,20:feedback,50:assigned';
$g_status_enum_workflow[CLOSED] ='20:feedback,50:assigned';
注意
工作流需要有一条从大于或等于 resolved 状态回到 feedback 状态的方式（参见 "Stage setting "一节中的 $g_bug_resolved_status_threshold 和 $g_bug_feedback_status），否则，重新打开的操作将无法工作。
注意
每个列表中的第一项表示该状态的默认值，它将在 "查看问题 "页面的 "更改状态 "组合框中被默认选择。
工作流涉及的权限
只有具有ADMINISTRATOR访问级别的用户 ，才能在"Manage > Configuration > Workflow Threshold "页面，设将工作流的权限赋给用户，以下是工作流的权限列表还有部分设置：
- 报告一个问题——允许报告一个问题。
- 更新一个问题——允许更新问题除工作流阶段外的信息。
- 允许问题在解决后关闭——允许在一个步骤中解决和关闭一个问题。
- 允许报告者关闭问题——表示是否允许报告者关闭他们所报告的问题。
- 监控问题——用户能够监控问题。一旦一个用户监控了一个问题，该用户将被包括在所有与该问题的变化有关的未来电子邮件通知中。
- 处理一个问题——用户被显示在可以处理一个问题的用户列表中。
- 分配问题——用户将问题分配与取消分配给处理人。
- 移动一个问题——用户能够将一个问题从一个项目移动到另一个项目。
- 删除一个问题——用户能够删除一个问题。
- 重新打开一个问题——用户重新打开一个已解决或已关闭的问题。
- 允许报告者重新打开问题——问题的报告者是否可以重新打开一个已解决或已关闭的问题。
- （设置）重新打开的问题所处的状态——这是一个问题被重新打开后所处的状态。
- （设置）重新打开的问题的处理状况设置为——对重新打开的问题处理状况设置为。
- （设置）问题被视为解决的状态——问题被视为解决的状态。
- （设置）只读问题的状态设置为——具有这种状态及以上的问题被视为只读。只读的问题只能由配置了的用户修改。只读适用于问题标题信息以及其他与问题相关的信息，如关系、附件、注释等。
- 更新只读问题——用户能够修改只读问题。
- 更新问题状态——用户能够修改问题状态。
- 查看私有问题——用户能够查看私有问题。
- 设置查看状态（公共与私有）——用户在报告问题时，能够设置问题是私有还是公共。如果报告问题的用户没有必须的权限，那么问题将以默认的视图状态创建。
- 更新视图状态（公共与私有）——用户能够更新视图状态（即公共与私有）。
- 查看监控问题的用户列表——用户能够查看监控问题的用户列表。
- 设置处理者分配的状态——当改变问题的状态时，用户能够重新分配问题。
- （设置）将自动分配的问题设置为——这是对自动分配给用户的问题所设置的状态，这些用户与报告者所在的类别有关。
- 限制报告人对他们自己的问题的访问——当设置时，报告人只被允许查看他们所报告的问题。
- 添加注释——用户添加注释。
- 更新注释——用户更新问题注释。
- 允许用户编辑自己的问题记录——表示用户能够编辑他们所报告的问题记录。
- 删除备注——用户删除他们自己报告的备注。
- 查看私有注释——用户能够查看与他们有权限查看的问题相关的私有注释。
- 查看更改日志——用户能够查看更改日志。
- 查看分配给——用户能够知道他们可以访问的问题的处理者。
- 查看问题历史——用户能够查看问题的变化历史。
- 发送提醒——用户能够向其他用户发送与他们所访问的问题有关的提醒。