Support Forums: Provide more contextual information in pending views

[Clorith]

When a moderator is releasing posts that are held for manual approval, they are expected to reassess the account at the same time.

There are various metric that are used in such a review, including why the account is flagged (if it is, there should be a user note, but it also happens that Akismet leaves posts in the pending queue if it feels something is "off", but it isn't absolutely certain it is spam), and how active the user is.

Currently, to assess the latter, one must visit the users profile, and visit the posts, replies, and reviews created by this user pages, modify the URL to include the view=all query string, and then go back in time and look at the activity.

We can improve on that flow. The "pending" view is a restricted one to those with the appropriate capabilities, so pulling relevant data is much easier.

We can start by introducing details such as when was the users last post archived (if ever); and if they have archived content, how much activity has the account seen since their last content which was found to not follow the guidelines.

By introducing these quick-references, we will significantly lower the barrier to completing "on the fly reviews" of accounts, and make it easier to assess (and unflag!) them, even in a busy part of the day where it may not always be easy to go through all those steps.

[Clorith]

Example view of the additional details shown when reviewing pending posts or topics. Showing how long it's been since the user last hard content archived (if ever), how many pending posts they currently have, and how many posts have been approved since any content was last deemed to not follow the support guidelines.

[Clorith]

6809.patch​ implements the view from meta-6809.JPG​ as a proposed solution.

A few points of interest;
The diff-viewer for whatever shows spaces (they are tab indentations :) )

get_user_posting_history uses two direct WPDB queries to fetch post counts, although often not great, in this case the count queries are quite self-contained with enough limiting parameters that this should in theory be fine to use, particularly in a specialized view such as we are working within.
The alternative would likely be to use get_posts for the counts as well, which would have had a much larger memory footprint as a trade-off, which would have a much larger overall negative impact I believe.

For those who do reviews: Is this the kind of view that would help make things more efficient for you?

[mrfoxtalbot]

This is awesome. My only feedback regarding the note itself, could we bold/highlight the numbers to make them harder to miss/overlook?

[Clorith]

6809.2.patch​ should be addressing some feedback.

It now bases its last archived content on the post modification time, this should prevent incorrect date-references when older content is retroactively archived.

It also provides a today feedback for archived content that is less than a day old, and chances the date lookups to all reference the *_gmt columns (for consistency, since those will always relate to UTC, unlikely to be a problem here, but it's open and someone else may look for inspiration).

And finally the pending count no longer has a date comparison (including this initially was not intentional, as the pending posts will be addressed and moved to another post status, so we want a full count, and the added complexity although minimal, was still unnecesarry complexity).

[Clorith]

In 12616:

Support Forums: Show context information about pending posts.

When viewing queues of pending posts, a moderator is expected to check a users history to make sure they un-flag users in as timely a manner as possible. Doing so generally requires going in and checking the users posting history manually via their profiles.

This change reduces the workload of moderators by providing a lot of this information within context of a pending post.

Fixes #6809.