As a follow-up on #881534: Allow to unpublish spam posts instead of rejecting, I did some coding tonight. I started implementing a rough prototype of the "comment spam queue" idea. The code is only 50% functional and has no tests, but the UI visualizes what I had in mind. I'm attaching both a screenshot and an early patch. The patch obviously needs work but I'm sharing it early so other people can step in to help. :)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | mollom-HEAD.queue_.1.patch | 6.53 KB | sun |
| spam-comment-queue-HEAD.patch | 5.37 KB | dries | |
| spam-comment-queue.jpg | 376.2 KB | dries |
Comments
Comment #1
sunAttached patch fixes the basics.
I agree that a "preview" (as currently contained with the truncated body) would be useful, but if we want to do that, then I think we should store a "teaser" (or post_title and post_body) in {mollom}.
That, in turn, would potentially enable us to remove the limitation for comments in the long run. Mollom could provide a single moderation UI for all posts that need to be moderated, regardless of entity... well, if there wasn't something like node access and eventually entity access... but yeah, I'm quite sure that we can find solutions for that.
Comment #3
taslett commentedThis looks like it will be really useful.
As an end user it would be great to have a quick link to block the author of the spam (if they are a registered user).
Comment #4
lizhenry commentedIt may be useful to add a "Reject" or "Report to Mollom as spam" option here too - unless deleting a Mollom-suspected comment already reports it as confirmed spam.
This kind of queue for regular nodes would also be very helpful to separate nodes unpublished by Mollom (which I've been calling "suspected") from other unpublished nodes - for example, separated from blog post drafts.