Actions integration for Spam module

You'd need some sort of User Voting spam filter module. I think it's a really good idea, but it's a bit outside the scope of the current module. Maybe for the next major version, or if someone wants to start up that module themselves.

Maybe the http://drupal.org/project/flag module could be used for this? Simply allow all users to "flag as spam", and then allow admins to check the flags later? You could even make a an action that marks a comment as spam after X users flag it...

Obviously this mean that you need another module, which probably isn't a good thing for a feature that probably SHOULD be part of the spam module, but it's probably a good work around, and I think that this feature should stay postponed until the 6.x is stable

Sure, that would work as a current workaround.

I sort of disagree that it should be "part of the spam module," as I think the spam module's gotten big enough as it is -- I think it should be a *separate* module that hooks into the API that the spam module provides for add-ons like that.

That being said, if somebody ends up submitting a patch to do all that, I'd be happy to entertain it.

Though now that I think about it, in 6.x the functionality isn't necessary. What *is* necessary is to integrate Spam with Actions (which is in core in 6).

When that is done, the Flag module is *exactly* the right way to do it. You let users flag items, set up a threshold in Flag, and have the threshold execute a "mark as spam" action (or maybe "send to moderation") provided by the Spam module.

That's probably the best way to do it in 5.x too; the change is likely to occur in 6.x first and then get backported to Actions 5.x-2.x.

And all this is not only a much better way to approach it, but *much* more likely to happen than an entire "user voting" module within Spam or separately.

I think this is great idea and would be really useful for busy sites.

Subscribing, let me know if any additional functionality is needed in Flag module, but I think that Flag should already provide all the APIs necessary to make this implementation trivial (in fact you might not need to do anything at all, other than make the action). Marking #522118: Integrate flag module with spam module as duplicate.

subscribing.

I'm surprised there hasn't been more interest in this feature. Seems like it would be extremely useful in handling spam.

subscribing, backing #7 :)

quicksketch: Agreed. After the namespacing fixes issue, this one is my top priority. (Of course, will also happily entertain a patch if anyone would like to give it a shot...)

Marked #284335: Allow users to report spam as a duplicate of this one. Some possibly germane related issues listed over there, too.

Damn d.o session management... I just lost all this...

Ok, here's a patch that just adds the actions. Once this is enabled, you can go to admin/settings/actions/manage to see them. Pretty, eh? Now if you install flag, and the included flag_actions, you can create a flag (say "Mark node as spam"), then you can create an action with a threshold of your choice that will allow users to mark a node as spam, and after enough users click it, it'll be marked as spam.

Depending on how your spam config is set up - ie. if your spam ISN'T set to auto un-publish, then you could create another, higher threshold to unpublish it.

I haven't tested this extensively, but the parts I did test worked.

I'm not sure what will happen if the threshold is reached, and it's marked as spam, and then an admin un-spams it - maybe the next spam flag will mark it as spam again? maybe quicksketch can answer that one.

It might be nice to allow the user the option to automatically create the flags/flag actions from admin/settings/spam, once it's been determined that the flag/flag_actions module are enabled.

I can't see how to get anonymous flagging working, but apparently it already does: #271582: Allow anonymous users to flag content

This is looking great! I've not used it yet, but this is very much headed in the right direction.

Before committing this, I'd like to this patch also remove any code where we're manually unpublishing users/nodes/comments, etc, making the spam module fully dependent on actions.

Also, what does it mean to mark a node or content or user as spam? Do we unpublish them? These types of things should no longer be decided by the spam module, they should instead be "built" by admins in the actions.

Finally, should we be adding any spam-specific triggers? Or does Drupal core and other content types provide us with all the triggers we already need?

Thanks for your effort on this!

Jeremy: Whoa, you sound like you're talking about a complete re-write of the spam backend...

At the moment, that patch just adds _action hooks that act as a front end for the main spam function. The reason there's six of them is that actions are defined as either node, user, or comment actions. The actual unpublish bit is decided by the spam function according to the settings page.

By the way, this still shows the comment actions, even if the comment module is not enabled. Not a huge problem, since the $cid checking will just mean that it does nothing, but it's a bit ugly. I guess I could add a conditional around the comment actions section in the spam.module.

I don't think it's a complete rewrite actually, but yes, it does remove a fair amount of kruft I hope. In any case, I'm fine with doing it in stages and starting with what you have, I believe. I do not have time/energy tonight to give this a real run through, though I did read through your patch already. I'll try and make time later this week and give it a test, and decide then whether or not it makes sense to do more.

If we can get rid of actions when they shouldn't be there, that would be great.

Ok, this checks if the modules are enabled first, before declaring the actions. saves on a bit of code duplication too...

New patch is better than the first, but it shouldn't be necessary. Actions to spam/unspam e.g. comments should be in the comments content module. Ditto for all others. These should not live in spam.module.

Should also handily solve the problem named in #13.

On another note, I don't think what Jeremy was asking for was really a rewrite of the back end (or, again, a rewrite of the content modules, as above) -- it'd really just be re-tasking the current spam/unspam functions as actions, and wherever they're called, replace those with action calls. Definitely still non-trivial, but the vast majority of the code can be reused.

The problem is that those .inc files aren't modules, there's only one declaration of the _action_info() hook, and that's gotta be in the spam.module. But it should be fine to move all the actual action code into the .inc files, which is done in this patch.

I would say that the possible re-write of spam to use actions should be split off into a separate issue.

I reckon this would make a lot of sense when combined with #342133: Request 3 way split - (spam/unsure/ham). That way, user-flagged spam could first be marked "possible spam" at some threshold, and "spam" at some higher threshold.

I would say that the possible re-write of spam to use actions should be split off into a separate issue.

Yup.

#200585: Allow Actions on spam/not-spam

I referenced this issue when adding another actions related issue: #742402: Integrate Spam module with Rules module.

Patch in #17 committed:
http://drupal.org/cvs?commit=478318
Thank you, naught101. It was a solid patch, and should've been committed long ago.

That patch includes mark_as_spam and mark_as_not_spam functionality. Should we include any others? Perhaps train_as_spam? Or something else I haven't thought of?

Answering my own question:

We'll want a "calculate_spam_probability" and a "test_for_spam" (which integrates the calculation of probability and the marking of spam/not spam, as appropriate).

Still curious as to people's opinions on whether we should also include "train_as_spam," though.

It would be neat to have something similar for Rules, especially since that's what D7 supports.

Thank you.
Alexis

I thought I addressed that before.

D7 supports Rules as a separate module -- just like it does in D6. (But it's Rules 2.x instead of Rules 1.x.) Rules is basically the next generation of the old workflow_ng module.

D7 still has Actions (and its triggers) in core, just like D6 does. And if somebody opts to use Rules, their Rules can still leverage Actions as implemented in Drupal core. So the real benefit here is from implementing core-style actions and triggers. The only thing we could do that would be Rules-specific is the calculate_spam_probability action I mentioned above, which probably isn't useful to implement as a Drupal Action but which really is pretty low return as far as functionality goes for a non-trivial time investment in implementing via Rules. That's not high on my radar.

As far as specific actions: do we need a "train_as_spam" action? Or is that too granular?

I would suggest we remove that "train_as_spam" since it does nothing in the module anyway. If you want to train the Baysian module, then you can simply call mark_as_spam, can't you?!

Thank you.
Alexis

As corrected in the related issue -- when I said "train_as_spam" I meant "train_as_not_spam." There is no "train_as_spam" op hook in the code. (Nor, as you point out, does there need to be.) What I meant to ask here is whether we'd want to implement a "train_as_not_spam" action, once we correctly inplement it in the module.

Patch enclosed adds "check for spam" functionality to spam.module and all three content modules, and adds a warning thrown if bad IDs are passed to the actions. (Also cleans up some incorrect comments in the code, for clarification.)

Since it looks like "train_as_not_spam" is not currently implemented, I'm going to push making an Action for that (if we want to) to the issue that deals specifically with train_as_not_spam. As such, I think this is the last patch required to make for a full implementation of this ticket.

3 little things:

1. "} else {" needs to be written on 2 lines (Coder style)
2. "...'.$type.'..." needs spaces before/after variables (at least)
3. In the following I would suggest a TODO: or XXX so we can easily detect/find those notes

 /**
  * API call to simply test if content is spam or not.  No action is taken.
+ * (incorrect? spam_mark_as_spam is called, meaning the content is marked as
+ * spam if the threshold is exceeded.)
  */

Other than that (and the fact that a function may not be doing what it is supposed to do) I did not see a problem. Wouldn't that work as a bulk update? Someone was asking about that, and there are modules to run commands on all the content (i.e. I have see a module that allows you to run a bulk update on all nodes from admin/content/content). That would be useful for people who install the Spam filter "later". Especially with a "train_as_not_spam" feature (assuming that the user has checked all the existing data before and deleted existing spam.)

Thank you.
Alexis

OK. I can make cosmetic changes on the commit itself.

Is that an RTBC of the code part of the patch itself? Does it seem to work as advertised, not break anything, etc?

As far as bulk updates -- I don't think there are actually any bulk update triggers are there? So on bulk update, what would happen is simply that individual triggers would fire one at a time for each content item.

Went ahead and quickly rerolled the patch with the style and comment changes.

That looks good. 8-) But I need to test to mark it as RTBC...

What action have you used to check? Just wondering how to make it work quickly.

Thank you.
Alexis

I want to say that I tested mark as spam and mark as not spam, but I fired them using some custom PHP because I had to test from a semi-production site. It'd be better to test them from triggers -- /admin/build/trigger/node, etc and pick, say, "when saving a new post" or something just to make sure the action works.

(...then again, it might not show up on the trigger list unless you modify the trigger code... that would be interesting.)

That patch in #17 that was committed and is in the current release does not work.

Every action - node, comment, and user - calls spam_mark_as_not_spam, even when you are trying to mark as spam.

So it will never mark anything as spam. In fact it will do the opposite.

mr.j,

I have a problem on one of my websites when I try to mark comments as spam in the comments approval queue. However, all other cases work for me.

Could you let us know in which case specifically does it fail for you? Is it the link on the page or the content lists or both?

Thank you.
Alexis

The actions integration does not work when marking as spam.
I don't know if that has anything to do with the comments approval queue.

The problem is in these 3 functions:

# spam_content_comment.inc
--- 1574
+++ 1575
@@ -405,7 +405,7 @@
   }
   // make sure we have a comment record
   if ($cid) {
-    spam_mark_as_not_spam('comment', $cid);
+    spam_mark_as_spam('comment', $cid);
     // record a message noting the action taken
     watchdog('action', 'Marked comment %cid as spam.', array('%cid' => $cid) );
   }

# spam_content_node.inc
--- 1574
+++ 1575
@@ -213,7 +213,7 @@
   }
   // make sure we have a node record
   if ($nid) {
-    spam_mark_as_not_spam('node', $nid);
+    spam_mark_as_spam('node', $nid);
     // record a message noting the action taken
     watchdog('action', 'Marked node %nid as spam.', array('%nid' => $nid) );
   }

# spam_content_user.inc
--- 1574
+++ 1575
@@ -267,7 +267,7 @@
   }
   // make sure we have a user record
   if ($uid) {
-    spam_mark_as_not_spam('user', $uid);
+    spam_mark_as_spam('user', $uid);
     // record a message noting the action taken
     watchdog('action', 'Marked user %uid as not spam.', array('%uid' => $uid) );
   }

Indeed! I'm not use the actions so never ran in this problem myself...

Thank you for the patch!
Alexis Wilke

P.S. I'm leaving the issue open since you're point, I think, is something different than the last patch proposed...

See
http://drupalcode.org/project/spam.git/commit/f1d53e4

Pretty sure mr.j's problem was fixed with the change in #36...