关于新的审核队列(2019)的反馈

If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?

End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue

4 个赞

This is an interesting use case and I’d like to help you get it working.

Actions for reviewable types are returned from the build_actions method.

What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.

That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.

8 个赞

Robin,

我目前正在为 Discord OAuth 插件 准备一个拉取请求(PR),主要目的是在 Discourse 中存储更多的 Discord 用户信息。我尝试使用你的 ReviewableUser 模型,以保留实现自动审批的功能。

由于当前实现是异步地为新用户创建审核记录,我需要检查是否已创建此类审核记录并将其清除。

不幸的是,我遇到了一个非常奇怪的 Ruby 错误,不知道你是否遇到过类似情况。

代码如下:

  def after_create_account(user, auth)
    super
    
    data = auth[:extra_data]
    if !user.approved && data[:auto_approve]
      user.approved = true
      user.approved_by_id = Discourse.system_user.id
      if reviewable_user = ReviewableUser.find_by(target: user)
          reviewable_user.set_approved_fields!(user, Discourse.system_user)
      end
    end
  end

一旦执行到 ReviewableUser.find_by,就会抛出异常:

*** NameError 异常:错误的常量名称 #<Class:0x000056134e417870>::DiscordAuthenticator

虽然我原本以为自己在 Ruby 方面已经取得了不错的进展,但我不清楚为什么会发生这种情况?

是路径问题吗?我尝试过多种 require 方式,但问题反而变得更复杂了。

这与核心代码中的其他类似模式非常相似。非常感谢任何建议!

如果需要,这是我的仓库地址:discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub

那个持续的错误提示没什么信息量,对吧!我认为这与 Rails 引擎和命名空间有关。你可以尝试一下在 ReviewableUser 前加上两个冒号,即 ::ReviewableUser。这会告诉它使用根命名空间,而不是引擎内的命名空间。

这段代码对于 reviewable API 来说看起来也有些过时了。它应该类似于这样:

if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
  reviewable.perform(:approve, Discourse.system_user)
end
5 个赞

这解决了错误。我猜是因为之前找不到这个类,所以它被当作常量处理了?不管怎样,问题已经解决了,太棒了,非常感谢!我终于脱困了!

所以我之前这样写:

      user.approved = true
      user.approved_by_id = Discourse.system_user.id

而不是:

reviewable.perform(:approve, Discourse.system_user)

是因为将用户加入审核队列是异步的。在后台任务中,只有当 approve 为 false 时才会创建审核记录(参见 discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub

    if user = User.find_by(id: args[:user_id])
      return if user.approved?

      @reviewable = ReviewableUser.needs_review!(
        target: user,
        created_by: Discourse.system_user,
        reviewable_by_moderator: true,
        payload: {
          username: user.username,
          name: user.name,
          email: user.email
        }
      )

存在一种风险:后台任务可能在你检查审核记录之后才执行?

结果是审核记录似乎不存在,但任务只是在等待执行。随后任务运行并创建了审核记录,而你检查的代码已经执行过了,因此错过了清除它的机会。

这算是一个潜在的竞态条件吗?

在检查审核记录之前将 approved 设置为 true,问题就解决了(因为在此之后不会再创建审核记录,这是依赖关系)。

我在测试代码时遇到了这个问题——在开发环境可以正常工作,但在生产环境却失败了,因为执行顺序不同。

附注:我理解你并未专门为这种用例编写此代码,但我认为允许插件在特殊情况下自动批准新用户是很重要的(例如 Discord 插件,如果用户属于受信任的公会,就会自动批准)。

1 个赞

确实,可审核记录是异步创建的,这在当前情况下会带来问题,因为登录会创建用户,而审批记录可能尚未生成。

更好的解决方案是在这种情况下不创建可审核记录,但这需要对核心代码进行修改才能正常工作。具体实现方式如下:

  • 认证结果可以返回一个类似 skip_approval: true 的字段。
  • 在核心代码中,如果认证结果包含该字段,则不创建可审核记录;如果仍需审批,则正确更新相关字段。
5 个赞

谢谢 Robin,是的。

目前我采用了变通方案,但清楚在直接 API 访问被移除之前必须解决这个问题。

团队是否有兴趣在移除直接 user.approve 写入权限之前优先处理此事?

我认为该变更将会破坏 Auth Discord 登录插件中当前的可信 Guild 自动批准功能(即使不考虑我刚刚为该插件提交的 PR)。@featheredtoast

如果该变更得以实施,我很乐意更新我的 PR 以支持这一变更。

我们近期不会移除这项权限。虽然我不希望永远依赖它,但它在一段时间内应该仍然有效。

3 个赞

队列界面很友好,而且“按主题分组”功能也很实用。

不过,据我所知,目前无法批量选择和处理帖子。每篇帖子都需要单独处理。

如果能支持批量选择和处理,将大大节省时间!

45

4 个赞

我认为这将是一个很好的改进。公平地说,标记队列从未支持过批量操作,所以这并不算是功能倒退。

此外,像“暂停”这样的操作在处理多行时会显得有些奇怪。为了使其合理,必须将其限制为基本操作。

8 个赞

发现一个小问题:有人在需要审核的类别中发帖,因此该帖子出现在审核队列中。他们发错了类别,我尝试在审核队列中修改它,本来没问题,但我要移入的目标类别要求必须带一个标签,而该标签仅限新类别使用;然而,审核队列中的帖子仍认为它属于原始类别,而原始类别不允许使用该标签,导致我卡住了。虽然批准帖子后再修改也不难,但这似乎是一个应该修复的问题。

5 个赞

我知道这本来应该被修复,但网址仍未被列入屏蔽列表。不过这可能其实无关紧要,因为针对屏蔽网址的操作本来就是“不执行任何操作”。只是有点奇怪。

请确认您是否已升级到正确的版本?如果不是 OneBox 兼容或内部版本,它们应该被过滤掉。

3 个赞

没错,我使用的是 v2.4.0.beta2 +66 版本。下次再出现这种情况时,我会复制该帖子。

是的,在审核队列中点击“删除用户”后,电子邮件和 IP 地址已被添加到屏蔽列表,但网址未被添加。该帖子内容为:

想要在线获取[学术写作服务](https://myassignmenthelp.com/uk/academic-writing-service.html)。全球排名第一的学术写作服务提供商 Myassignmenthelp.com 提供专业学术写作服务,为学生提供最广泛的选择和最优价格。
1 个赞

据我所知,URL 从未被自动添加到屏蔽列表中?好吧,我想它们确实被添加了,我检查了我的实例,发现里面有一堆 URL;)

啊,对了,我想起来了。它们实际上不起任何作用,仅用于提供信息。

您可以将这些域名添加到受监控词汇中,这样它们就无法被输入,但需要您自行操作。

因此,如果能将它们加入屏蔽列表会很好——即使不对这些 URL 采取自动操作,也能让我们看到正在发布的垃圾内容。请注意,版主可以使用审核队列,但(我认为)无法添加受监控的词汇。

1 个赞

一些轻微的 UX 反馈:如果审核队列能记住我的设置就太好了。由于我们与一个版主团队合作,我个人主要希望查看新的举报,并按“创建时间”排序,但这个设置无法“保存”。

7 个赞

这不算一个坏建议。幸运的是,目前有一个变通方法——搜索筛选条件会保存在查询字符串(URL)中。如果您将某个筛选条件加入书签,随时可以返回查看。

4 个赞