We’ll get those fixed up! We could possibly replace them with custom links - I don’t think that’s a bad idea! It would enable people to link moderators directly to their own guides.
Something we looked into is using the assign feature from the Assign plugin. We hit some technical difficulties early on, but it’s something we want to look into again, especially now that Assign is bundled in core.
This is also something we’ve discussed as an improvement, but haven’t built it yet.
I like all of your other suggestions (4 through 9)! We’ll do some investigation on our side to see how feasible these are to implement. Thank you for logging feature requests for each of them - it makes it easier for us to keep track of it all
I recall some recent work in this area - I’ll dig through that and see what’s going on. This won’t be anything to do with the new layout, as the same reviewables are appearing here as in the old layout. It sounds like we could maybe tighten things up there a little.
This is interesting - I’m not sure how feasible this will be inside the reviewable UI, but we can investigate to see what’s possible.
These are reasonable requests - while we could certainly add settings for these, we’ll need to do some research into the best way to make this possible, while ensuring the product remains easy to configure.
Along with the Revision Reason it would also be useful if the content of the Feedback that was included by the moderator when using the Revise post option was displayed*, so that other moderators/administrators have visibility in the review queue and the review item page of what the feedback was. *Perhaps in an expandable/collapsable way so as not to overload the page.
The Scrub record button ( Reject an applicant and delete the information they supplied - #26 by pento ) on Rejected User items (/review?additional_filters=%7B%7D&sort_order=score&status=rejected&type=ReviewableUser) doesn’t seem to be available on the new layout - just wondered if that was intentional?
@hugh - Is there a plan to add additional options for when a user is flagged upon registration as being suspicious?
Currently there are only 3 options to handle the user: Approve user, Delete user, Delete and Block user.
Will there be the options to Keep user silenced or Suspend User?
Since there are automated PMs that go out to the user upon the decision, it can be very confusing if we want to keep the user silenced due to an internal review, but need to clear the flag from the queue so we approve the user and a PM goes out and then we silence the user for further review. So the user is getting unnecessary PMs that are conflicting.
The issue is only with the review entry for approving new users - the email address and the custom user fields do show up (but not for Moderators since the Moderators view emails setting is disabled). However, we only use that feature on our dev instance and not on our actual forum, so it doesn’t affect us in the way I had thought.
Our dev instance hadn’t actually had any flagged posts, so I thought the fields in the approvals entries in the review queue was universal for all items. After testing a flagged post, I can report that the email and user fields don’t show up for those.
A suggestion: when copying the moderation note to the user profile, append a link to the review item, so other moderators can see the context of the comment.
Maybe something like this:
---
This comment was originally attached to review item <a href="/review/12345" title="From {time_ago}">#12345</a>.
I was just looking at user notes and realized that it took some clicking around to find the original review item. It isn’t as simple as just manually copying the URL of the page where the comment is left and pasting it in the comment, because the review comment might be written on a dynamic view like this:
Remove this claim button is not available because the example review is already actioned (rejected). Information on who actioned is visible in the Timeline & notes tab.
Can you please provide an example of why a moderator might want to unclaim after review is resolved?
두 가지를 비교해 보다가, 의도적으로 포함하지 않은 것이 아니라 단순히 놓친 것일 수 있어 강조해 두었습니다. 해당 기능이 이전 검토 대기열 레이아웃에 존재했으므로, 그럴 만한 이유가 있다고 생각했습니다.
모더레이터는 검토 대기열에서 ‘신고 접수자’ 필터를 사용하여 자신이 접수한 항목들을 처리할 수 있습니다. 따라서 조치 완료 후, 해당 항목이 ‘신고 접수자’ 목록에 다시 나타나지 않도록 접수 상태를 해제할 수 있으면 유용할 것입니다. 또한, 원래 접수자가 해당 항목의 접수 상태를 유지하고 있는 경우, 다른 모더레이터가 항목을 검토한 후 다른 조치를 취할 수 있습니까?
