Improve spam/unspam/approve/unapprove

[Ipstenu]

Currently if you spam or unspam (or approve/unapprove) a post, you go to a new page in the same window that handles the process.

1. We need that to be ajax if possible. If not (which is understandable) can it default open in a new window?
2. We need some message that says what you just did. Right now you can't tell until you check the mod options

[Ipstenu]

FYI, this is generally only an issue on the spam/pending views. Since there, we click 'approve' and end up losing our place in line. So the workaround is this:

• See pending. Right-click Approve (or spam) and open in new window
• Close new window
• Refresh

It's not terrible but it's not great. Lower priority IMO.

(Also I'm not worried about two people pending/unpending the same posts. That was always an issue)

[Ipstenu]

Related. We need more distinct flagging of moderated posts/topics

• Unapproved and spammed topics should say so when previewing
• "this post/reply is hidden from view' - like we do with plugin!!
• Flagged users have a flag or make the 'unflag' thing red - more obvious. Name in red?

Also spamed replies and archived are both red, while pending are light yellow. The following colors might be more helpful, based on the color cues we use for plugins:

• Keep spam red -- red == closed
• Make archive purple (or yellow) -- yellow is for 2 years sans updates, so 'old'
• Make pending blue -- blue is for 'needs approval' :)

[Clorith]

Also, these are all toggles, which means if two people are looking at say the pending queue and both approve a post, it is now un-approved.

[SergeyBiryukov]

Replying to Clorith:

Also, these are all toggles, which means if two people are looking at say the pending queue and both approve a post, it is now un-approved.

Moved to a separate ticket: #2418

[Clorith]

Few things are as frustrating as forgetting to open in a new tab when going through these lists, let's get this sorted out sooner rather than later.

Low hanging, but great QOL improvement for our mods.

[Clorith]

1965.patch​ Tries to tackle the various aspects considered in the original ticket description.

It makes use of the bbpress body class filter to add singular bbPress view class for targeting the spam and pending views only (as this makes little sense to use in a regular thread elsewhere). I also opened a ticket to have this done in bbPress at some point in the future, at which point the filter adding will gracefully degrade, and not add duplicates.

I made some conscious decisions on some of the displays and how it was implemented, which have some drawbacks, but for the most part are beneficial.

The JavaScript to fire the request is just doing a GET request to the regular link address, this saves us having to build a lot of ajax-ready nonces for the page all the time.
If the request fails, the post blinks and a notice saying the request could not be completed is prepended to the message body.

If the actions is completed, the post also blinks, and then shows a message stating the action (spam, pending or archival) was changed for the post. It does keep the "header" that shows what post/topic it was, in case you hit the wrong button it's then much easier to open the thread in a new tab (this was done since there's no direct ajax action, and thus we can't dynamically update the admin links).

Removing the post content is made so that it's easier to work you way through the view and have things, for the most part, go away once it's handled.

As for why it states the status was changed, this is because the approve/unapprove spam/unspam etc all have the same class reference, nothing distinguishes the two states for our targeting, so this was the better approach.

[dd32]

Milestone renamed

[dd32]

Milestone renamed

[dd32]

In 10660:

Support Forums: Ajaxify the actions (spam/archive/approve) on views.

Props Clorith, dd32.
Fixes #1965.

[dd32]

In 10665:

Support Forums: Limit the Ajaxification to the views, rather than also applying to threads.

Amends [10660].
See #1965.

[dd32]

In 10669:

Support Forums: Adjust the ajaxification of the view reply actions to not block open-in-new-tab and to only suffix a notice, rather than removing the content entirely.

See #1965.

[dd32]

In 10670:

Support: Bump cache buster after [10669].

See #1965.

[dd32]

In 11571:

Support: Attempt to fix the ajaxification of topic admin actions on views.

See #1965.