Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is perhaps out of scope for this module but it would save steps in moderating. On the screen that lets you choose how to report the spam, it would be nice to have checkboxes to ban user and ban the IP all in one shot.
Michelle
Comment | File | Size | Author |
---|---|---|---|
#14 | 245689.diff | 2.87 KB | drumm |
Comments
Comment #1
zooki CreditAttribution: zooki commentedHas this been implemented yet??
If not, what would be the right solution?
Also, can we configuer Mollom to not allow certain keywords / URLs..
Comment #2
Dries CreditAttribution: Dries commentedThe Mollom screens can probably extended to provide that functionality. For the banning itself, we could leverage the IP blocking functionality that is part of Drupal core. This should be easy to implement.
Comment #3
MichelleNice. :) When I asked this a year ago, I was totally on Drupal 5. I've now moved all but one site to D6 and that one is in progress. So I'm changing my request to D6. :)
Michelle
Comment #4
Dave ReidMarked #603174: Delete comment AND block user AND delete all comments by user as a duplicate of this issue.
The best way to accomplish this would to integrate actions with the report to Mollom page. Here's a quick mockup of how it would work:
Comment #5
Dave ReidBetter yet might be to have 'reported node to Mollom' and 'reported comment to Mollom' available as a trigger which can be assigned actions normally.
Comment #6
sunBy implementing #717212: Remove "report to Mollom" links and integrate with entity delete confirmation forms instead, you will be able to install "whatever" module that integrates with the existing forms, i.e. existing modules. Not duplicating functionality. Not sure whether such a module exists though, but at least Comment module already integrates with trigger/actions and related modules.
Therefore, I'm inclined to mark this won't fix. Thoughts?
Comment #7
sunRevised title. Bumping to 7.x.
Comment #8
sam_squarewave CreditAttribution: sam_squarewave commentedI keep getting spam accounts and this feature would be killer.
Comment #9
sunComment #10
drummComment #11
drummAttached is a patch for this. The integration works consistently with the core admin content pages.
Comment #12
eshta CreditAttribution: eshta at Acquia commentedSo Mollom currently has defined actions to delete comments and nodes and unpublish them after the work here: https://www.drupal.org/node/655846
Seems like the goal of this request is to include the Mollom delete form confirmation on regular delete actions within vbo as well. Am I reading this right? If so:
This feels very hard-coded. We have a hook (hook_mollom_form_list) where entities have their Mollom configuration defined. This includes access handling for reporting to Mollom. We'd need to check that at the least. We also allow for a delete callback in this configuration. I understand that the callback provided is for a single deletion. Perhaps we either 1) expand the configuration to allow for multiple; and/or 2) if that's not provided utilize the delete callback in the configuration to handle each deletion. Feels like this should be generalized to apply to all Mollom-supported entities rather than just nodes/comments.
Comment #13
drummMollom currently has
mollom_action_unpublish_comment
andmollom_action_unpublish_node
, but no delete and report action. The message I got from #655846: Mollom Actions was that this issue should be used to extend the delete action, similar to the core content admin pages.I think the hard-codedness of this is on par with
mollom_form_node_admin_content_alter()
andmollom_form_comment_multiple_delete_confirm_alter()
. There is a bit more logic since VBO is more flexible, and I decided to adapt code from_views_bulk_operations_get_field()
rather than call that internal function.Comment #14
drummAttached is an updated patch for this. I've only tested comments and nodes, so those are the only two entity types supported. And that's in line with what I can see works with
_mollom_actions_access_callbacks()
The first two changes in
_mollom_actions_access_callbacks()
fix handling of$info['report access']
, which is an array of permission strings, not an individual permission string. The final change makes getting the allowed entity IDs back out a little easier.(If the thinking has changed since #655846-2: Mollom Actions and adding
mollom_action_delete_{node|comment}
next to the unpublish actions is actually the way we want to go, I can go in that direction.)Comment #15
drummAnything I can do to help review here? Is the general approach okay?
Comment #16
eshta CreditAttribution: eshta at Acquia commentedHey there - haven't forgotten this. We'll need to shift focus into solving the problem for Drupal 8 and working backwards to Drupal 7 (although I realize the same conversation will still be relevant - but the answer may be dictated by what we decide in Drupal 8). Right now there are a bunch of test failures for Mollom on Drupal 8 that I'm working through and then coming to this is the next!
Comment #17
drumm