Codestream: [VS][功能请求]在MR列表中显示MR的批准状态

@ftcy0118 - 感谢所有反馈！ 在这种情况下，一旦 MR 获得批准，就不要在“等待”部分显示它们是否有意义？

这可能是个好主意！ 在我的日常工作流程中，我仍然对一些我不接受的批准的 MR 感兴趣。 例如，如果一个 MR 被其他人审查和批准，但我对标题看起来很感兴趣，我仍然会看一下。 另一种情况，如果一个 MR 被我批准了，但我注意到评论数量增加了，我会去检查新评论。

也许您可以为这些添加另一个列表？ （虽然 GitLab merge_requests页面只列出了所有具有批准状态的 MR。）

我认为应该有分配给用户的 MR，不包括他们批准的那些。 在我的情况下（一个自托管的 Gitlab），我看到了所有的 MR，甚至那些我没有分配到的 MR。

在我的工作流程中，我们同时使用“已分配”和“审阅者”字段。 我同意@vmohir 的观点，我希望在候补名单中看到我被分配或审核的 MR，但我尚未批准。

我倾向于@ftcy0118所说的。 我喜欢有一个明确的 MR 列表，他们期待我采取行动。 但我也想了解所有进入 repo 的新代码。
也许我们可以为那些我们没有创建或未分配给的 MR 提供一个额外的列表，并带有最终可配置的过滤器，以便我们可以准确地选择要在此列表中看到的内容？

虽然空间很小，但我会以不同的方式处理它。 IMO 命名可以从Waiting for my review更改Open Reviews 。
对于我是审阅者的评论，它可以被推到顶部并有一个图标显示我的注意力是必需的，当我批准 MR 时，我有一个小的绿色复选标记，表明我已经批准了它。
即使在我批准它以监控评论和更改之后，我仍希望在开放栏中看到评论。

也许我们可以为那些我们没有创建或未分配给的 MR 提供一个额外的列表，并带有最终可配置的过滤器，以便我们可以准确地选择要在此列表中看到的内容？

@christophedcpm - 你今天实际上可以做到这一点。 如果您单击合并请求部分标题中的过滤器图标，您将能够基于自定义查询创建一个新的子部分。

虽然空间很小，但我会以不同的方式处理它。 IMO 命名可以从Waiting for my review更改Open Reviews 。
对于我是审阅者的评论，它可以被推到顶部并有一个图标显示我的注意力是必需的，当我批准 MR 时，我有一个小的绿色复选标记，表明我已经批准了它。
即使在我批准它以监控评论和更改之后，我仍希望在开放栏中看到评论。

@aderopoa - 这样做的方式是，一旦 MR 获得批准或关闭，它就会从“等待”部分移到“最近”部分。 您认为这是否达到了您的要求，还是您更喜欢开放部分的想法，其中 MR 会一直保留到关闭？

虽然空间很小，但我会以不同的方式处理它。 IMO 命名可以从Waiting for my review更改Open Reviews 。
对于我是审阅者的评论，它可以被推到顶部并有一个图标显示我的注意力是必需的，当我批准 MR 时，我有一个小的绿色复选标记，表明我已经批准了它。
即使在我批准它以监控评论和更改之后，我仍希望在开放栏中看到评论。

@aderopoa - 这样做的方式是，一旦 MR 获得批准或关闭，它就会从“等待”部分移到“最近”部分。 您认为这是否达到了您的要求，还是您更喜欢开放部分的想法，其中 MR 会一直保留到关闭？

我认为需要有一个开放部分，MR 会一直保留到关闭为止。 从团队的角度来看，团队更容易联系到尚未审核的工程师。 开放部分告诉我，仍然需要采取行动来结束审查。 可能是我的批准或其他团队成员的批准。

我认为我们将继续合并 Waiting 和 Assigned 部分，但不幸的是，GitLab 看起来不像通过他们的 api 公开 MR 的批准状态。 不过，我们仍在探索各种选择……

不幸的是，由于 GL api 的限制，实际上我们在这里无能为力。 如上所述，我们无权访问批准状态。 此外，旧版本的 GitLab Self Managed 不支持审阅者，所以目前，我认为我们不能结合 Waiting 和 Assigned 部分。

对于那些不真正使用审阅者或受让人的人，我的建议是创建一个自定义查询以显示所有打开的 MR（状态：已打开）。 只需单击“合并请求”部分标题中的过滤器图标。

我们所做的一项更改将适用于@vmohir ，如果您使用的是不支持审阅者的旧版 GitLab Self Managed，我们会自动将 Waiting on my Review 部分替换为 All Open 部分.