感谢反馈，我们正在开发一个修复方案，以恢复正确的上下文。
2 个赞
感谢 @awesomerobot 为解决此问题所做的工作。
我的论坛已更新到 Discourse 版本 ed00bce10a9e2ad5f12f6ae6b3a229bb62cf2d2b，该版本包含 discourse/discourse#43495。但我们仍然在“用户需要审批”（User Needs Approval）的审核项中看到这些意外的按钮。
也许之前的报告表述不够清晰。问题并不在于缺少上下文。问题在于，我们已经通过标记审核界面（flag review interface）暂停了该用户，从而解决了这个审核项。对于一个已解决的审核项来说，完全没有理由还保留这个“是”（Yes）按钮。它只会造成混淆，让人误以为还需要执行额外操作才能完成审核，但它提供的唯一操作是批准该用户，而这对于垃圾信息发送者来说毫无意义。其他类型的审核项在审核完成后都不会显示按钮，而且这些按钮之前也不存在于“用户需要审批”的审核项中。
这显然是一个 Bug，而不是“用户体验”（UX）问题。
2 个赞
啊，我明白了，感谢你补充的详细信息，这确实需要理一理……我原本以为这是我们之前在审核队列（review queue）变更中遗漏的问题，但实际上这是另一个变更带来的副作用，而这个变更本不应影响审核队列。
原始问题是：当 must_approve_users 开启时，那些审核队列中的条目已被处理、但用户仍处于未批准状态的用户，无法通过他们的管理页面被批准，因为批准操作仅对待处理（pending）的条目有效。修复方案允许即使存在已处理的队列条目也能批准用户。这解决了管理页面的问题，但也导致审核队列中已处理的条目上出现了批准按钮。
所以，与其修复上下文，不如像你说的那样，让那个批准按钮不再出现。我正在准备一个修复方案，将再次在审核队列中隐藏该按钮：
1 个赞
一旦再次遇到同样的标志，我就会将第 6 号帖子标记为解决方案。
感谢大家的努力。
1 个赞
好的，问题似乎已经解决了。
这个论坛上的“解决方案”按钮在哪里？我预期它应该位于帖子下方的图标栏中。
1 个赞
Moin
9
已解决插件在此分类中未启用。你可以在例如 Support 等分类下的主题底部找到该按钮。
有时，当有人分享了一个变通方案（而非最终解决方案）后，用户会将主题标记为已解决。因此，在此分类下的主题中，会添加 fixed 标签，并由修复问题的人关闭该主题。
2 个赞
