提案：整合审查队列

贡献 功能
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 话题里：

在「排队帖子」中，曾发生过几次帖子或话题被误拒的情况。目前，用户界面中没有任何功能可以撤销此操作。是否可以考虑添加一个拒绝日志并提供恢复选项，或者允许管理员和版主恢复被误拒的帖子？

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 个赞