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

**URL:** <https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837>\
**Category:** Announcements\
**Tags:** new-feature, review-queue\
**Created:** [2019年三月28日 16:50 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837 "2019-03-28T16:50:12Z")\
**Posts on this page:** 20\
**Page:** 12

<div class="post-metadata">

**Author:** ![fzngagan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fzngagan/32/259349_2.png) [@fzngagan](https://meta.discourse.org/u/fzngagan)\
**Post date:** [2020年九月3日 10:44 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/239 "2020-09-03T10:44:19Z")

</div>

> [@bartv](#):
>
> ActiveRecord::RecordNotFound 这一行很有趣，因为每次我尝试从审核队列中删除用户时都会出现，而且涉及的主题 ID 完全相同。

是的，当删除用户时，我们会将他们从已确认参加的任何活动中移除。可能是那段代码导致了这个问题。

---

<div class="post-metadata">

**Author:** ![bartv](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bartv/32/130052_2.png) [@bartv](https://meta.discourse.org/u/bartv)\
**Post date:** [2020年九月3日 10:46 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/240 "2020-09-03T10:46:22Z")

</div>

> [@merefield](#):
>
> 你为什么认为“活动”模块参与其中？

因为错误中涉及的所有主题 ID 都是使用了“活动”功能的主题。

> [@fzngagan](#):
>
> 是的，当用户被删除时，我们会将他们从已 RSVP 的任何活动中移除。也许这段代码导致了这个问题。

嗯，我相当确定我正在删除的这些特定用户并没有进行 RSVP，不过也有可能这些是唯二启用了 RSVP 功能的主题？

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2020年九月3日 10:47 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/241 "2020-09-03T10:47:27Z")

</div>

哦哦，明白了。

> <https://github.com/angusmcleod/discourse-events/blob/85cc5a5c01e67135d8b06d5a386aa56192fb294c/plugin.rb#L301>

@fzngagan 这里用的是不安全的 `.find(` 吗？

`topics = Topic.find(topic_ids) if topic_ids`

参考我刚才推送到 Follow 插件的 [修复](https://github.com/paviliondev/discourse-follow/commit/b523b3aee2d2f0e01934ef63131bc85e3c7caf34)（不过这里的解决方案可能需要不同，因为涉及多个 ID——是否应该使用 `where`？）

---

<div class="post-metadata">

**Author:** ![bartv](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bartv/32/130052_2.png) [@bartv](https://meta.discourse.org/u/bartv)\
**Post date:** [2020年九月3日 10:57 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/242 "2020-09-03T10:57:37Z")

</div>

我刚更新了，但仍然收到 404 错误。

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2020年九月3日 10:58 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/243 "2020-09-03T10:58:33Z")

</div>

Bart，请稍等，待 @fzngagan 应用并确认修复。

---

<div class="post-metadata">

**Author:** ![fzngagan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fzngagan/32/259349_2.png) [@fzngagan](https://meta.discourse.org/u/fzngagan)\
**Post date:** [2020年九月3日 11:22 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/244 "2020-09-03T11:22:23Z")

</div>

我已推送了一个修复。希望这能解决问题。请检查并确认。

---

<div class="post-metadata">

**Author:** ![bartv](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bartv/32/130052_2.png) [@bartv](https://meta.discourse.org/u/bartv)\
**Post date:** [2020年九月3日 12:19 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/245 "2020-09-03T12:19:40Z")

</div>

问题解决啦，谢谢！！

---

<div class="post-metadata">

**Author:** ![tmomas](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tmomas/32/109144_2.png) [@tmomas](https://meta.discourse.org/u/tmomas)\
**Post date:** [2020年九月7日 17:52 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/246 "2020-09-07T17:52:44Z")

</div>

我多次在审核队列中看到这样的帖子，其审核原因为“新用户发帖速度异常快”。  
经过进一步检查，我发现这些帖子包含受监控的关键词，但审核队列中并未提及这一点。

由于“新用户发帖速度异常快”的标记有 96% 的情况是错误的，而“受监控关键词”的标记 100% 正确——也就是说，如果帖子因包含受监控关键词而进入审核队列，那么它 100% 是需要关注的帖子——我认为“受监控关键词”的优先级应高于“新用户发帖过快”。

想象以下两种情况：

1. 帖子因“新用户发帖速度异常快”进入审核队列。该帖子包含一个隐藏在受监控关键词列表中的隐形垃圾链接。→ **帖子被批准** ，因为没人注意到隐形链接（例如链接隐藏在“.”之后）。→ 失败！
2. 帖子因包含受监控关键词进入审核队列（“受监控关键词”优先级高于“发帖过快”）。该帖子同样包含一个隐藏在受监控关键词列表中的隐形垃圾链接。→ **帖子被拒绝** ，发垃圾信息的用户因“受监控关键词”被删除。→ 成功！

---

<div class="post-metadata">

**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\
**Post date:** [2020年九月8日 17:36 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/247 "2020-09-08T17:36:01Z")

</div>

> [@tmomas](#):
>
> 我觉得“被监视的词汇”应该优先于“新用户输入过快”。

完全同意，这确实是一个临界漏洞。我们能否将此任务添加到某人的待办列表中，@eviltrout？我看到@Roman 仍然被指派了，或许可以交给他？

---

<div class="post-metadata">

**Author:** ![Roman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/roman/32/157504_2.png) [@Roman](https://meta.discourse.org/u/Roman)\
**Post date:** [2020年九月9日 17:38 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/248 "2020-09-09T17:38:25Z")

</div>

已在此修复：

[https://review.discourse.org/t/fix-we-should-check-for-watched-words-first-even-if-the-user-is-a-fast-typer-10630/15111](https://review.discourse.org/t/fix-we-should-check-for-watched-words-first-even-if-the-user-is-a-fast-typer-10630/15111)

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2020年九月14日 04:57 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/249 "2020-09-14T04:57:21Z")

</div>

关于 2.6.0.beta2 版本。提个醒，我发现有些已排队的主题似乎已被删除。我认为发生这种情况的流程大致如下：

- 由于用户输入过快，其帖子被放入审核队列。
- 他们删除了自己的主题（如果这是可能的），可能是为了重新提交。

我不确定这是否符合预期。在审核队列中，标题显示为空白，但帖子正文依然存在，且该用户已被禁言。在用户的公开资料中无法看到任何主题或帖子。

* * *

**与上述内容无关。** 我对筛选选项有个建议。我认为一个非常棒的功能是提供更细粒度的帖子/主题类型筛选。目前“类型”选项包括：

 ![discourse-types](https://global.discourse-cdn.com/meta/original/3X/a/6/a6f69ea3f059977620d0a66ab5b8699eb0399419.png)

“标记的帖子”和“排队的帖子”同时包含主题和回复。我认为将其改为以下内容会非常实用：

审核类型：

- 已标记
- 已排队

或许还可以考虑将“已标记”进一步细分为“用户标记”和“系统标记”。

此外，再增加一个用于内容类型的筛选器：

内容类型：

- 主题
- 帖子
- 用户

我认为这会非常有用。例如，可以更快地优先处理主题审核，而非帖子/回复审核。目前的筛选器除了“按主题分组”外，几乎没有其他方式可以区分主题和帖子。

* * *

另一个建议是调整审核队列的界面，使主题和帖子更容易区分。目前这些信息仅以一些小的灰色文本显示（例如：排队的帖子、排队的主题、标记的帖子、标记的主题）。该文本大小与帖子/主题的分类和标签大小相同。

对我来说，很难立即判断某项内容是主题还是帖子/回复，我经常将两者混淆。

一些想法：

- 调整帖子项中的“主题标题”部分，添加一个 [回复图标](https://fontawesome.com/v4.7.0/icon/reply)，使其比主题项更小，并可能包含“回复：”文本；
- 增大项目类型（主题/帖子）的文本大小或强调程度。

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2020年九月26日 16:11 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/250 "2020-09-26T16:11:13Z")

</div>

尝试批准主题和帖子时，我遇到了 500 错误。当前使用的是 2.6.0.beta3 版本。以下是日志：

```
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'

```

一些可能相关的信息是，我过去曾安装过 Akismet 并已将其卸载（也执行了 rake 任务），详情参见：[Feedback on the new Review Queue (2019) - #210 by markersocial](https://meta.discourse.org/t/feedback-on-the-new-review-queue/112837/210?u=markersocial)

这些项目来自过去 60 天内（auto\_handle\_queued\_age: 60）。我尝试过处理旧帖子（约 2 个月）和最近（过去 3 小时内）的帖子。

我可以批准用户（类型：User），并且“删除用户”选项在排队中的主题/帖子上也能正常工作。

---

<div class="post-metadata">

**Author:** ![eviltrout](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eviltrout/32/5275_2.png) [@eviltrout](https://meta.discourse.org/u/eviltrout)\
**Post date:** [2020年九月28日 15:28 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/251 "2020-09-28T15:28:16Z")

</div>

@Roman 这个情况非常奇怪——我们怎么会得到一个这么大的整数？

---

<div class="post-metadata">

**Author:** ![Roman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/roman/32/157504_2.png) [@Roman](https://meta.discourse.org/u/Roman)\
**Post date:** [2020年九月28日 18:05 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/252 "2020-09-28T18:05:23Z")

</div>

在尝试创建通知时抛出了错误：

> <https://github.com/discourse/discourse/blob/main/app/models/reviewable_queued_post.rb#L97-100>

我怀疑我们可能正在以某种方式存储数据。

也许我们使用 `int` 类型存储了一些 ID？Rails 从 5.1 版本开始对主键使用 `BIGINT(8)`。

> <https://github.com/rails/rails/pull/26266>
>
> \<blockquote class="twitter-tweet" data-lang="en"\>\<p lang="en" dir="ltr"\>Friends …don&#39;t let friends use INT as a primary key. \</p\>&mdash; Schneems (@schneems) \<a href="https://twitter.com/schneems/status/731167572096253952"\>May 13, 2016\</a\>\</blockquote\>
> 
> \### Summary
> 
> Per a conversation with @sgrif: changes default primary keys from Integer to BIGINT for both Postgresql and MySQL. Leaves behavior alone for SQLite since this database does not provide support for BIGINT primary keys.
> \### Other Information
> 
> For obvious reasons, this also requires foreign keys to change from integer to bigints. As a result the test suite's \`schema.rb\` has been change in the necessary places.
> 
> I'll squash and add a CHANGELOG entry once the rest looks ok...

@markersorcial 您能否与我们分享这些查询的结果？

```ruby
Notification.count
User.count
Topic.count

```

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2020年九月29日 01:17 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/253 "2020-09-29T01:17:52Z")

</div>

感谢您对此事的关注 🙂

好的，这是查询结果：

```plaintext
Notification.count: 1506604
User.count: 238083
Topic.count: 936067

```

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2020年九月29日 10:10 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/254 "2020-09-29T10:10:03Z")

</div>

更新：我在 Sidekiq 中发现大量任务失败，错误信息与此类似：

```
Jobs::HandledExceptionWrapper: 封装的 ActiveRecord::RangeError: PG::NumericValueOutOfRange: 错误：整数超出范围

```

涉及的任务类型（截至目前我注意到的）：  
Jobs::PostAlert（最常见）  
Jobs::ProcessPost  
Jobs::NotifyCategoryChange

---

<div class="post-metadata">

**Author:** ![eviltrout](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eviltrout/32/5275_2.png) [@eviltrout](https://meta.discourse.org/u/eviltrout)\
**Post date:** [2020年九月29日 14:27 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/255 "2020-09-29T14:27:10Z")

</div>

这些数字都不应该超过最大限制。我想知道是否有其他内容覆盖了整数值 @Roman。

---

<div class="post-metadata">

**Author:** ![Roman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/roman/32/157504_2.png) [@Roman](https://meta.discourse.org/u/Roman)\
**Post date:** [2020年九月29日 15:27 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/256 "2020-09-29T15:27:03Z")

</div>

那一定是别的问题。肯定有什么情况在发生，而且并非特定于审核队列。

这些作业会创建通知，但它们也失败了：

> [@markersocial](#):
>
> Jobs::PostAlert（最常见）  
> Jobs::ProcessPost  
> Jobs::NotifyCategoryChange

另外，如果我尝试执行类似这样的操作：

```ruby
Notification.create!(
      notification_type: Notification.types[:post_approved],
      user_id: 1,
      data: {},
      topic_id: 1,
      post_number: 1311344111111
)

```

我会得到另一个错误：

```plaintext
ActiveModel::RangeError: 1311344111111 超出了 ActiveModel::Type::Integer 4 字节的限制范围

```

执行以下操作时也会得到相同的错误：

```ruby
DB.exec <<~SQL
      INSERT INTO notifications(user_id, topic_id, post_number)
      VALUES (1, 1, 1311344111111)
    SQL

```

`PG::NumericValueOutOfRange: ERROR: integer out of range`

---

<div class="post-metadata">

**Author:** ![Roman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/roman/32/157504_2.png) [@Roman](https://meta.discourse.org/u/Roman)\
**Post date:** [2020年十月1日 22:02 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/257 "2020-10-01T22:02:22Z")

</div>

@markersocial 我想知道 PostgreSQL 日志是否能帮助我们获取更多关于该错误的信息。您能帮忙检查一下吗？

如果您不知道在哪里可以找到日志，请参阅：

> [@Where does Discourse store and show logs?](https://meta.discourse.org/t/where-does-discourse-store-and-show-logs/58022?u=roman_rizzi):
>
> When troubleshooting issues or errors with Discourse it is important you look at your logs. Here’s a listing of where they are and what’s in there. Your site domain Administration logs shown in the UI The Discourse admin panel contains several forms of logging: Emails that are sent, skipped, bounced, received and rejected are logged at https://=DOMAIN=/admin/email-logs and the neighboring tabs. Staff actions are logged at https://=DOMAIN=/admin/logs/staff\_action\_logs Email addresses an…

---

<div class="post-metadata">

**Author:** ![Mark\_Schmucker](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mark_schmucker/32/124810_2.png) [@Mark\_Schmucker](https://meta.discourse.org/u/Mark_Schmucker)\
**Post date:** [2020年十月6日 07:49 UTC](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837/258 "2020-10-06T07:49:19Z")

</div>

我们的版主非常欣赏能够在彼此之间轻松讨论“标记帖子”，并且相关历史记录会保留在审核队列中。是否可以为“待审帖子”添加同样的功能？我们使用 approve\_post\_count 设置，要求新用户的前 5 篇帖子必须经过审核。这前 5 篇帖子会成为“待审帖子”，但如果需要版主讨论，他们就必须发起私信，这将脱离审核队列，导致历史记录丢失。

[上一頁](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837.md?page=11)

[下一頁](https://meta.discourse.org/t/feedback-on-the-new-review-queue-2019/112837.md?page=13)