我没有找到重现此问题的方法，但在过去的一个月里，我注意到有两个用户据称已被停用（从员工操作日志中可以看到），但实际上并未停用（用户仍然可以登录）。
例如，这个用户在 29 天前被“停用”，但今天仍然能够给我发送私人消息（停用后的唯一其他员工操作是“检查电子邮件”）。
这是另一个（不同的员工能够在 4 小时后再次“停用”同一用户，而之前没有重新激活）：
我使用的是 2.9.0.beta9。
此问题仍在进行中（每月发生几次）。其他人注意到过吗？
这是控制器代码
StaffActionLogger 工作正常，但我怀疑 User.deactivate 方法中的某些内容可能失败了。
错误共同的特点是它们来自 API 请求。我通常使用：
PUT https://<MY_SITE>/admin/users/<USER_ID>/deactivate
Api-Username:<ADMIN_USER>
Api-Key:<KEY>
data: {"context":"/admin/users/<USER_ID>/<USER_NAME>"}
我总是收到“success: OK”
还有其他日志可以检查或尝试的事情吗？
我使用的是 2.9.0.beta11
此情况仍偶有发生。例如，该用户最初于 8 月 23 日被“停用”，但我现在才注意到他们仍然处于活动状态，并已将其停用。
用户如何能被停用两次（中间没有重新激活）？
我有一个日常任务，它运行一个查询来检查这种情况。昨天没有返回任何结果，但今天返回了这一个用户，所以似乎发生的情况是，用户在 8 月 23 日被正确停用，但不知何故昨天又被激活了（没有任何记录）。
是否有可能通过 API 或 UI 激活用户而不留下痕迹？我假设这只能通过直接修改数据库来实现，而我确信我没有这样做（我是唯一的管理员）。
这种情况可能会发生。已停用的用户只需尝试登录网站，然后点击发送给他们的激活邮件中的链接，即可重新激活其帐户。
当已停用的用户尝试登录时，他们会看到此模态框：
Discourse 会向他们发送一封“确认您的新帐户”电子邮件：
点击邮件中的链接后，用户将登录 Discourse。
据我所知，这一直是这种行为。我不认为这是一个错误，但我也可能弄错。向已拥有帐户的用户发送“确认您的新帐户”电子邮件似乎有点奇怪。
编辑：要获得您想要的行为，您可能需要“暂停”用户而不是停用他们。
4 个赞
谜团解开了！谢谢你，西蒙。你可以关闭这个帖子。
1 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.