Associate feedback with related spam log

Feedback is a mechanism for users to report when they have been blocked by the spam filter. It gives the admin a chance to review the node content, and have it posted if in fact it is legitimate content. It was designed to be difficult to spam -- and so far I've never had spam end up in the feedback section. It is not a node. It's actually a complete capture of the form used to post a node (or comment), but as of yet unposted as it was blocked by the spam filter.

It should be possible to link to the debug log, assuming that the log still exists. It may prove difficult because blocked content will not have an ID...

In any case, there's no link to the node as at this point the node does not exist. A link to the author could be added, assuming they are a logged in user and not anonymous.

Ok, that's completely different to what I expected.

It seems a little disjointed to completely halt feedback'd spam in the process of posting, while allowing real spam to be posted(/unpublished).

So:
- provide link to node (not currently possible)
- provide link to user (should be possible)
- provide spam log entry in feedback response form (should be possible, might require adding the log to the feedback data?)
- provide higher level logging for feedback'd spam (probably not currently possible without running spam checks twice?)

The third one is probably the only really useful one that's worth implementing.

> It seems a little disjointed to completely halt feedback'd spam in the process of posting, while
> allowing real spam to be posted(/unpublished).

This is only because the filters aren't perfect. The goal of course is to block 100% of spam postings and 0% of non-spam postings. The reality is that we may allow some spam through and we may block some non-spam postings too. The goal of feedback is to allow humans posting this non-spam to say, "hey, my post wasn't spam but you blocked it! Can you please post it?" and to allow the admin an automated way of posting the content.

> - provide link to node (not currently possible)

The node doesn't exist, so it will never be possible.

> - provide link to user (should be possible)

Yes, should be easy.

> - provide spam log entry in feedback response form (should be possible, might require adding the log to the feedback data?)

When the spam content was filtered, it generated logs. The catch is figuring out how to link these logs with the feedback -- agreed that it should be possible. Perhaps matching on uid? Or IP, if an anonymous user?

> - provide higher level logging for feedback'd spam (probably not currently possible without running spam checks twice?)

I don't understand?

Re: disjointed. This probably isn't as applicable on regularly moderated sites. I help to run an open publishing site that supposedly has other moderators, but they don't seem to get around to the spam, so I'm left to deal with it, which I do, once a week. Users seem to get agitated that their false positives get held in limbo. But I guess that would be the case any way you do it.

#2 - also, option to email user when feedback'd post is published.

for #3, would it be possible to make the main filtering function tack the log data onto the form? Or even better the pre-log data?

#4 - for example, if the logging level site wide is set to "disabled" or "important", it would still be useful to have full verbose or debug level logs to give some context to the false positive.

> Re: disjointed. This probably isn't as applicable on regularly moderated sites. I help to run an open
> publishing site that supposedly has other moderators, but they don't seem to get around to the
> spam, so I'm left to deal with it, which I do, once a week. Users seem to get agitated that their
> false positives get held in limbo.

What would you suggest as an alternative?

> #2 - also, option to email user when feedback'd post is published.

If this feature is added, I'd like to see it made optional when posting feedback. A checkbox that says, "Notify me of your decision about my posting." and if the user is anonymous also a textfield for collecting their email address.

> for #3, would it be possible to make the main filtering function tack the log data onto the form? Or even better the pre-log data?

I see what you're getting at -- it would be quite useful to understand why the spam filter blocked the content. I just reviewed a whole back log of feedback and much of it was blocked for no obvious reason. I agree this would be useful.

> #4 - for example, if the logging level site wide is set to "disabled" or "important", it would still be useful to
> have full verbose or debug level logs to give some context to the false positive.

That's not really possible. This is a performance issue -- if you've disabled logs, they really need to be disabled. Unless, as you say, you re-run the content through the filters just for this purpose, which is in theory possible. And as noted above, it would certainly make this functionality more useful.

I added the author for nodes and comments. I also added the date the content was posted. And finally, I make a best-effort attempt at linking to any existing logs.

Having done this, I realize I should have held off until we had a stable release --whoops.

Here's the commit:
http://drupal.org/cvs?commit=247212

Yeah, I was just about to say that. :-)

We do in theory have a beta release -- it's tagged in CVS, I promise! I don't know why the release bot hasn't picked it up yet; it's been a few days now. Going to check in a few to see if I somehow screwed up the format. Must be some silly mistake like that.

It's waiting for you to 'Add new release' from the Spam project page. :) Tagging it in CVS is only the first step.

Yeah; I meant that I wasn't seeing it "add new release" -- turns out the beta1 release wasn't showing up on the "add new release" page for me because of my overly agressive caching proxy. (My fault; I configured it!) It's now been rolled and should be out soon. Obviously this commit is not in it, nor are any of the commits from the past couple of days.

As most of this issue's been taken care of, retitling to address the bit that remains. We all seem to agree that this would be useful functionality.