Make it more obvious that form submissions from user 1 are not filtered

Empty Mollom statistics report is meaningless, see #783452: Add warning about the statistics graph not being real-time.

In a Webform 6.x-3.0-beta5 form with Mollom 1.13, I'm also making a submission that is chock-full of "Viagra" spamminess and it still goes through. However, I don't get any log entries or anything to help narrow it down.

The form is configured to have every field analyzed. It contains 3 text fields, an email field, and a textarea.

The settings form says "We contacted the Mollom servers to verify your keys: the Mollom services are operating correctly. We are now blocking spam."

This is the only log entry from Mollom: "Refreshed servers: http://174.37.205.152, http://88.151.243.145, http://88.151.243.81"

An additional observation: both the mollom and cache_mollom tables are empty. Table mollom_form has what I'd expect.

form_id: webform_client_form_56
mode: 2
enabled_fields: a:5:{i:0;s:20:"submitted][your_name";i:1;s:29:"submitted][your_email_address";i:2;s:28:"submitted][your_phone_number";i:3;s:26:"submitted][message_subject";i:4;s:23:"submitted][your_message";}
module: webform

If you're submitting it as user 1 or a user with the 'bypass mollom protection' it's always going to go through. Try as an anonymous user (or put your Mollom subscription into development mode and use the 'spam', 'unsure', or 'ham' keywords).

Testing again as an anon user triggered the spam filter as expected, so that much is good. Thanks.

However, that's still a usability issue. Could you record that the check was skipped because of permissions somewhere? Watchdog alone would be OK, but providing a total along the lines of "5 submissions skipped Mollom validation today" might be better.

Maybe we should document it on the Mollom form configuration page? Maybe we can add a sentence as part of the usability work done in #785460: Users have a hard time understand how exactly the Mollom mode is set?

An obvious warning somewhere in the config pages would definitely be helpful, and I think that's good regardless of other actions taken. A paragraph about how to test that Mollom is working correctly could be better.

Logging submissions skipped because of permissions has more utility than a static message, since it lets you figure out how often it actually happens. It's not a big deal with good instructions.

Setting to Active (since it doesn't really need to be waiting on me at this point), but Duplicate might be more appropriate if you do combine the issues.

Thanks.

I think this would actually be a good feature for a dedicated 'developer mode' like proposed in #415014: Add an in-module developer mode toggle.

That is, adding a sentence stating that form submissions from user #1 are not sent to Mollom (or those who have the 'by pass Mollom' permission set, for that matter).

Well, I'd say that the information is equally useful for site maintainers and developers. Really anyone who'd be able to see the Mollom config pages.

Everyone using Drupal should be familiar with the special-casing of uid 1 regarding user permissions, so it is sufficient to clarify that there is a user permission that allows to bypass Mollom's protection.

And that, we want to put prominently into the primary help text:

I don't think it's a safe assumption that user 1 knows what they're doing in any way. Having uid 1 really just means that you are capable of running the install script, which doesn't require any Drupal-specific knowledge at all.

However, I'm still pretty satisfied with the help text. The info at http://mollom.com/tutorials/drupal (link from INSTALL.txt) covers basically anything else they might need to know.

Thanks!

I don't think it's a safe assumption that user 1 knows what they're doing in any way. Having uid 1 really just means that you are capable of running the install script, which doesn't require any Drupal-specific knowledge at all.

That may be true, but my point is that documenting this in Mollom module would be the completely wrong place. If that special-casing of uid 1 throughout Drupal is not clear, then Drupal core's documentation needs to be improved. Otherwise, each and every module would have to duplicate this info almost everywhere, ultimately leading to duplicate information, effectively leading to users no longer reading help texts.

You are definitely right about it being a core issue. I'll search around and open an issue if need be.

Looks good and I agree with the conclusion not to worry about user ID 1.

In both Drupal 6 and Drupal 7 we can actually link to admin/user/permissions#module-mollom and admin/people/permissions#module-mollom, respectively. Except that it is a bit broken in Drupal 7 due to the table header, it seems.

Added the fragment.

That D7 patch surely won't pass on D6. :)

#17: mollom-DRUPAL-6--1.bypass-help.17.patch queued for re-testing.

Committed to CVS HEAD and DRUPAL-6--1. Thanks sun!