Spam filters are not enabled until you visit filter settings page
Jeremy - August 6, 2009 - 15:35
| Project: | Spam |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Enabling a spam filter module is not enough to enable the spam filter. You have to visit the Administer >> Site configuration >> Spam >> Filters page and then they are actually enabled. This is confusing and can make you think you're filtering spam when you're not.
This could be made much simpler with a single variable "spam_filter_install". Any time a spam filter module is enabled, we delete this variable. The spam module would check for this variable and if not-existing it will run the install process and set the variable.
It would be easy to implement, but I will try and respect our beta period and not implement until we get a stable release out... ;)
#1
That's a really good point. That's surely expected behavior. I don't know what you think about this, but I'm almost tempted to treat that as a "UI bug" -- because when the end user clicks "enable," he's going to think something's wrong when it's not enabled, so to the end user that's a bug. We're just looking to have new spam filters enabled by default instead of disabled, right? That does seem pretty straightforward.
The only reason I think I *wouldn't* do this now is that, if we were going to start fixing up the filter modules with an .install file like a "grown-up" module :), I'd think it'd be appropriate to do that along with the namespacing fixes for them (node_age* -> spam_node_age* and such). And I'd earlier said that can wait for a 2.0. Then again, I wouldn't mind at *all* having that done earlier rather than later, and I think a few global search/replaces are probably pretty straightforward too.
Yeah, I really like that idea -- the more these modules look like a real, separate spam-api-based module, the more likely somebody is to use one of them as a template for their own add-on spam module. Makes things like #365375: TypePade AntiSpam API being contributed more likely.
#2
I'm a big believer in implementing fixes when you've got the time/energy to do it, and as such if you want to fix the namespace issues, etc, before rolling a -beta2, I'm not going to stop you! :)
As for this issue...
The following filters already have their own install files: bayesian, custom, duplicate
The following filters would have to have install files added: node_age, surbl, url
If you choose to tackle the namespace issue, I'll happily tackle this issue.