我正在使用MantisBT来跟踪问题，到目前为止，已经收集了许多问题。但是，我的变更日志仍然为空
无可用的更改日志信息。项目包含问题 版本和问题已通过设置“版本固定”解决。
每个错误报告都有 产品版本，目标版本（路线图需要）和固定版本（变更日志需要）。 同样，我已经发布了某些版本。
我已经自定义了我的工作流程，我怀疑这是部分原因。
# custom access list
$g_access_levels_enum_string = '10:VIEWER,20:REPORTER,30:ENGINEER,40:CCB,90:ADMINISTRATOR';
# custom resolution list
$g_resolution_enum_string = '10:OPEN,20:REOPEN,30:WONTFIX,60:DISPOSITIONED, 70:FIXED';
根据我的判断，需要显示更改日志 1）发布版本（完成） 2）具有与此版本匹配的固定版本的错误（完成 3）已关闭为“已修复”的错误
现在使用新的MantisBT（并且测试显示更改日志有效），FIXED的常数为20，所以我一部分怀疑这是我的g_resolution_enum_string，但这也意味着应该有另一个变量设置应该使用哪个阈值< / p>
$g_bug_resolution_fixed_threshold = FIXED;
这不起作用
我想念什么？另外，如果它很重要...我的版本也被标记为：v0.0，v0.1，v0.2（即以'v'开头）
答案 0 :(得分：0)
我建议您特别阅读文档的Enumerations section
此处枚举中包含的字符串仅供参考
因此，您的70:FIXED枚举定义实际上与常量 FIXED 不匹配，正如您所指出的那样，该常量仍设置为20，这意味着 $ g_bug_resolution_fixed_threshold < / em>实际上指向您的20:REOPEN ...您可能想定义自己的常量。
还要注意，在此情况下还有一个重要的阈值$g_bug_resolution_not_fixed_threshold-高于该阈值的分辨率被认为是无法成功解决的。默认情况下，它设置为_UNABLE_TO_REPRODUCE_（40）。
换句话说，要使问题出现在变更日志中，它必须符合以下所有条件（reference）：
请注意，可以使用custom function更改此标准行为。
因此，您的问题确实是由您的自定义 resolution_enum_string 引起的，很可能是与上述2个阈值中的值结合使用的。