你好，我在几次 Discourse 更新之前就开始遇到一个问题：系统会通知有新用户等待审批，但当我查看审核队列时，却发现队列是空的。
这种情况仅发生在单个用户请求审批时。如果有多个用户在等待，我可以看到队列中除了一个之外的所有人，但总有一个不会被包含在内。
换句话说，很多人无法成功注册。
在另一条 帖子 中，有人建议可能是多选插件（multi-select plugin）以某种方式介入，导致 Discourse 将队列长度多加了 1。
综合来看，这似乎不太可能，因为必须存在某种触发机制，导致某些天会收到通知，而另一些天则不会。此外，这个问题并非在插件安装时出现，而是在几个月后才开始发生。我只能将其与某次 Discourse 更新关联起来（因为我相信此后没有安装其他插件或进行其他更改）。
有人遇到过类似情况吗？可能的解决方案是什么？
顺便问一下，@jjaffeux，您之前对这个插件所做的“修复：使值解析更具弹性”的修改，是否可能与这个问题有关？
那么这个插件是仅与核心 Discourse 功能相关或基于其构建的吗？我不太清楚。
您好，我也不太清楚，会不会是两者共同导致的？
这个问题并非在插件首次安装时出现，而是在几次核心更新之后才开始的。如果插件确实有关联，或许存在某种非预期的交互？
我暂时无法通过卸载插件来测试问题是否持续，因为该插件至关重要——用户注册审核依赖于他们只能在该插件激活状态下提供的回答（用户需要从下拉列表中进行选择）。
GitHub - procourse/discourse-multiselect-user-field · GitHub 实际上不应该作为一个插件，因为它只包含 JavaScript。
我首先的建议是等待进入“不良状态”……然后在浏览器中启用安全模式，查看队列是否正常。
如果在安全模式下看起来正常，你可能需要在 Marketplace 发帖，将该插件转换为主题组件，并根据 Discourse 的最新模式进行更新。
你好，谢谢 Sam。
不幸的是，在安全模式下结果相同——即使我进入启用了 Discourse 安全模式（已禁用所有三项站点自定义项目）的页面，针对待审核用户的通知中，队列里仍然少了一个待审核的用户。
这说明了什么？
可能需要一位审核队列专家来查看此主题。我会标记此问题，有人将在接下来的几天内与您联系。
提供复现该问题的确切步骤将会非常有帮助。
谢谢，Sam。
很难确定具体的步骤——我不确定自己做了什么可能不寻常的操作，也无法将问题的出现归因于某个特定事件。
在我看来，主要的嫌疑对象要么是 Discourse 的更新，要么是 @j.jaffeux 在 3 月 14 日对多选插件进行的更新，该更新旨在“使值解析更具弹性”。
问题在于新注册非常零星，有时几周都不会有一个，因此因果关系在时间上可能相隔很远。
您能否使用 Chrome 无痕模式并创建虚假账号，自行复现该问题？
我想我需要指定一个有效的邮箱地址，这样申请才能进入队列？
我没有尚未用于测试的邮箱地址——所有邮箱都已注册了账户。
如果您有 Gmail 邮箱，可以使用加号地址功能……jane+something@gmail.com 会发送到 jane@gmail.com。
好的，这很有趣——我尝试按上述方法使用我的 Gmail 账户，但即使我在另一个浏览器窗口中打开 Gmail 网页并等待 Discourse 生成的验证邮件到达，我的常规管理员邮箱地址却收到了关于需要审核的新注册的通知（而队列依旧为空）。原来是我输错了地址，因此从未收到发往 Gmail 账户的邮件，也从未完成验证。
因此，除非这只是巧合，否则管理员通知是否可能过于仓促？但这无法解释为何每条通知都恰好对应队列中一个缺失的人员—— presumably，并非总是只有一个申请人未能验证邮箱，而其他人都成功了。
** 编辑 **
随后，我在该无痕模式注册窗口中更正了我的 Gmail 地址，并重新发送了验证邮件——该邮件随即出现在我的 Gmail 浏览器窗口中。我在另一个无痕窗口中通过验证链接成功完成了验证。此后，我的管理员邮箱未收到任何后续通知，因此我只能假设第一条通知确实与这次新的注册尝试相关。
我又打开另一个浏览器窗口，以安全模式再次访问网站，以管理员身份登录，看到队列中仍然显示有一人待审核——但这次我的新测试账户已可见，并且可以被批准。
以上情况是否有助于厘清问题？
跟进一下：我再次尝试，通过无痕窗口创建了一个新的虚假账号（首次即输入了正确的地址）——此次尝试按预期成功，通过普通浏览器窗口回复管理员邮件通知时，我看到新用户在队列中可见。
随后，我通过标准窗口再次尝试注册，并通过标准窗口回复通知（全程未使用无痕模式或安全模式）——一切再次正常运作。因此，问题（或者可能是两个问题：申请人在完成邮箱验证前就向管理员发送了通知，以及未完成或已完成的申请未出现在队列中）仅限于第一次尝试。
再次说明，我不确定这是否增加了多少清晰度——但也许当系统首次注册出错（生成了虚假通知）后，后续的注册就能正常进行？或者，在长时间无后续注册活动后，系统会回退到故障模式？
你好 @Paul_King
我怀疑在我提到的那个提交附近添加的一次迁移导致了此问题，使得一些未批准的用户看起来像是在审核队列中，并引发了奇怪的通知。
你能否在数据浏览器中运行以下查询以确认这一点？
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE
你好，Roman。
我刚运行了该命令，假设我操作正确（见截图），计数为零
。不过，我的 Discourse 安装目前也显示没有等待审核的用户。我刚刚又创建了一个虚假账号并完成了地址验证，但至今我的管理员邮箱没有收到任何通知。我重新以管理员身份登录站点，再次运行了查询，计数仍为零，但这次 Discourse 正确地报告有一位用户正在等待审核
。通常情况下，通知管理员有待审核用户的邮件几乎是即时发送的，所以我相当确定这封邮件从未发出。现在问题几乎反过来了！
*编辑 - 我刚刚收到通知，说有两位用户正在等待审核（尽管出现了不寻常的延迟）。不过，汉堡菜单旁的小红图标仍显示数字“1”，点击进入审核队列时，却只看到我上面创建的那个虚假用户注册记录——我批准了该用户，Discourse 随后提示没有更多待审核用户。
此后我再次运行了查询，计数为零。
抱歉，我意识到 WHERE 子句有误。应该是 r.type = 'ReviewableUser' 而不是 User。
能否请运行这条语句？
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE
那一定是别的问题了。我会调查一下。
嘿 @Paul_King，
能否麻烦你检查一下你的站点是否存在没有关联可审核对象的未批准用户？我目前一直在尝试复现这个 bug，但尚未成功。
以下是用于查询的 SQL 语句：
SELECT COUNT(*)
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL
另外，也可以尝试：
SELECT COUNT(*) FROM users WHERE approved = false AND active = true
这仅表示该账户正在等待批准。
SELECT * FROM users WHERE approved = false AND active = true
用户名将是一个指向用户资料的链接。在识别出该用户后，能否分享一下 created_at 日期？我想知道我们是否在该日期前后更改了某些内容。
