提案：統合レビューキュー

貢献 特徴
23

Personal stuff continued to get in the way of implementing this feature but I’ve finally got some progress to report.

I’ve hit a milestone of full use of the review queue for flags, with full backwards compatibility for the old flagging REST API. There is still some interface stuff left to do and some site settings left to replace, but I’ll probably be ready for review some time next week.

There are a huge amount of changes here so I do expect some regressions, but the good news is the next Discourse release has quite a long time to go, so there will be time to iron them out.

I ran some benchmarks on the new /review.json endpoint vs the old /admin/flags/active.json and the results are promising:

  • Old code: 51ms (Views: 0.1ms | ActiveRecord: 26.9ms)
  • New code: 21ms (Views: 0.1ms | ActiveRecord: 4.4ms)

So it’s about 2.4x faster overall, and spends about 15% of the time in the DB as it used to!

「いいね！」 22
24

ここでのこの提案は妥当だと思いますが、もし不適切であれば、別の Contribute > Feature トピックに移動することも可能です。

現在、キューに入れられた投稿が誤って却下される事案が複数発生しています。その際、UI上にはその操作を取り消す機能がありません。却下ログに復元オプションを追加するか、管理者やモデレーターが誤って却下された投稿を復元できる何らかの方法を実装することは可能でしょうか？

「いいね！」 11
25

Yes, absolutely. I haven’t made the “Old Reviewables” tab yet but the idea is you could go there and perform any valid actions on them.

「いいね！」 9
26

It’s been a while since I posted a screenshot. This is a fully working review queue, showing flagged posts.

As you can see, you can now filter by reviewable type (queued posts, users, flags, all) and by minimum score.

image
image2255×1170 203 KB

The UX still needs a designer pass, but it’s awesome that the interface is working smoothly now.

「いいね！」 17
27

I have a small structure question.

Can the review queue client UX live in a dedicated JS payload? It would be nice if we only shipped it to users with access to the review queue (ideally when they first navigate to it)

「いいね！」 9
28

One challenge is right now there’s no easy way to know if someone has access to the review queue, because the new data structures support category level moderation. The current user payload comes back with a reviewable_count for all users (usually 0).

It’s not impossible to solve this, but I have a lot of other things on my plate right now to get this feature done. Maybe we can revisit later.

「いいね！」 6
29

I implemented this today. Instead of a tab, you can filter by “Pending, Approved, Rejected, Ignored”. It’s simple and works great. You can also filter by category, in case a moderator only wants to see content from a particular category.

image
image2252×338 39.7 KB

「いいね！」 12
30

On this subject, Ember has started some very interesting work on code splitting:

「いいね！」 7
31

Okay, as promised here’s the (large) PR:

https://github.com/discourse/discourse/pull/7128

I imagine it will take some time to review but it would be good if a couple people at least could look it over.

「いいね！」 23
32

I spent a fair amount of time reading this PR today. And damn this is impressive @eviltrout :heart:

You even updated the bot, the import scripts, the user merger, rake tasks, the reports…

And I really like the design so far :heart_eyes_cat:

「いいね！」 25
33

Yes it was a lot of work, but thank you! Honestly our extensive test suite really helped me track down usages of internal APIs and test backwards compatibility. Two months is a long time to spend on a feature like this, but it would have been so much longer if we hadn’t done our jobs properly in the past.

「いいね！」 21
34

The plan is to merge this on Wednesday morning (eastern time), after we cut and deploy a new beta. At that point I’ll probably create a new topic for feedback / bug reports.

「いいね！」 15
35

Update: We didn’t merge this yet. There was a Rails security vulnerability and some other risky changes in core we wanted to avoid. It’s deployed here on Meta and we’re going to dogfood the branch a bit more before we merge it.

「いいね！」 10
36

Okay we’ve merged this in. It’s no longer a proposal, so there is a new topic to discuss the feature.

「いいね！」 11