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!
I think this makes sense here, but if not, I can move it to a separate feature topic:
There have been several occurrences of a topic or post being accidentally rejected when it was in Queued Posts. Currently, there is nothing in the UI to undo this action. Would it be feasible to include a rejection log with a restore option, or some way to allow admins and mods to restore a post that was rejected by mistake?
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)
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.
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.
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.
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.
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.
