This is the result of me missing moderators permissions when migrating old posts. The bug was fixed but in your case the migration already ran. I have considered adding a second migration to fix this, but I feel like very few people were affected so it’s easier if they fix it themselves.
Is it possible that you could run the following code in a rails console: ReviewableFlaggedPost.update_all(reviewable_by_moderator: true)
However, that makes me realize that the history section is less useful. We can show what happened to those reviewables inline. I ran it by @awesomerobot and I think what we’ll do is drop history, and update the scores area to have the following columns:
| flag type (with score) | flagged by (with %) | reviewed status | reviewed by | reviewed ago |
I do not think history should show expanded by default. At minimum it should be behind a button to expand it. This is something I asked for in my mockups.
It would be helpful if there was a tab or quick button that shows all recent activity for the past few days. On the previous system, one could simply select the Old Flagged Posts tab to view this information without the need to select criteria from a drop-down list.
I recall being able to click the View Pending link, and having the reply pop up on the page. Now, instead it redirects you to the “Needs Review” page. I often strongly prefer to read pending comments on the page in question, instead of reading it on the review page. This is because often it can be difficult to judge someone without context, so i end up going back and forward to read previous replies, and reading the pending reply.
We currently have some messages that are stuck in our review center. They’re flagged as ‘spam’ by the system and selecting ‘Disagree and Restore Post’ leads to an internal server error. I just did a rebuild and the issue remains.
Started PUT "/review/1627/perform/disagree_and_restore?version=0" for XXX at 2019-04-10 09:14:17 +0000
Processing by ReviewablesController#perform as JSON
Parameters: {"version"=>"0", "reviewable_id"=>"1627", "action_id"=>"disagree_and_restore"}
Completed 500 Internal Server Error in 128ms (ActiveRecord: 77.4ms)
NoMethodError (undefined method `[]' for nil:NilClass)
/var/www/discourse/lib/post_destroyer.rb:191:in `user_recovered'
I’d prefer to wait and see if others find the new interface disagreeable for this purpose, as it’s only an extra click or two. In the meantime you can bookmark /review?status=reviewed in your browser to jump to the latest reviewed things.
I just reviewed the code pre-review queue and “view pending” was a link to the queued posts URL so I’m not sure how it could have worked.
It looks like we had a bug in our “post recover” code, where if the post was edited but not its body, it would throw an error. This should fix it:
This new view is showing scores everywhere, but nothing really explains what the scores mean. Is it related to settings like “score to auto close topic”? What determines the score of a flag? Is higher worse? More likely to be accurate? From a more trusted user?
(Sorry, I don’t have any ideas about how the scores could be helpfully explained UI-wise. Maybe a link to a blog post in the side bar?)
Today I added something @sam has wanted for a while. As a user, the experience when one of your posts ended up in the queue wasn’t great. You’d get a pop up that said it was awaiting approval, but then you’d have no other indicator of what’s going on.
Now, thanks to the above commit a user will see their pending posts in the topic they will land in. They can also delete them if they change their mind.
The actual formula has quite a few steps and I think would have to be displayed in some kind of rich tooltip. But we could try something really simple like this?
This score is calculated based on the trust level of the reporter, the accuracy of their previous flags, and the priority of the item being reported.
Not sure how critical this is but on the Review queue the system repeatedly adds the same reason over and over again to the queue for a single given item (New User)
I noticed this too. Does not seem to affect the functionality at all but there is a list of 2 or 3 of the same reason for some items.
update with my screenshot, same behavior as @Jose_C_Gomez. But not caring as much about protecting privacy of my spammers. I will leave it like this for a while and see if it gets a third report.