| Project: | Mollom |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Dave Reid |
| Status: | closed (fixed) |
Issue Summary
I'm not sure when it changed, but I no longer get "Report as Inappropriate" links on site-wide contact-form originating mail. I guess this is by design - e-mails that are forwarded or replied to would otherwise have preserved the link, and the link would be being sent to recipients that (rightly) would not have permission to manipulate a site's Mollom setup by flagging mail as spam.
Is there any way by which I can flag a mail as spam? It makes no difference, of course, to the one mail that has got through. But it would be good if we could keep training Mollom by doing this. Otherwise, Mollom isn't going to learn about the latest mail spam techniques.
I'm sure it must be there somewhere (hence this Issue is flagged as a Support Request not a Bug Report or Feature Request). I just can't find it. It's not in the dblog entry for the mail, or in the Mollom settings or reporting pages. Can anyone help?
Comments
#1
That's odd because we tightened up the restrictions for which e-mails include the link, but the site-wide contact e-mail should be one of them that does get the report link. I'll do some testing today to see if I can duplicate this.
Also note that the actual report mail link is actually broken in the latest stable release and will be fixed in the next release: #602044: Contact reporting functions missing from mollom.pages.inc
#2
Well I found a bug with the message IDs being used, but we have an even bigger problem. The condition in mollom_mail_alter():
isset($GLOBALS['mollom_response']['session_id'])is NULL even when I'm using the site-wide contact form and had to fill out a captcha.#3
...in which case, it's time for a category change...
#4
On it.
#5
Tested with latest code and we still are not inserting reporting links in e-mails. There is nothing in $GLOBALS['mollom_response'] at all despite the fact that I had to fill out a CAPTCHA on a contact form. Bumping to critical as this breaks functionality.
#6
Let's try to get this one fixed as it could hold up a release.
#7
This fixes the part related to contact module integration. The other part (no session id) is going to be fixed via #674230: Broken mass-reporting, session storage, node title mapping, watchdog messages, administrative user creation form ;)
Note on tha patch: It's a bit unfortunate that we get two entirely different responses for a validation request to mollom.com. Ideally, checkContent + checkCaptcha would be just mollom.validate, dynamically testing the CAPTCHA value if there is one, but otherwise, taking into account all values we are able to send. Interestingly, this is the unforeseen continuation of a mail I just wrote earlier this evening. ;)
errr, now that I look at that patch once again, this will break when trying to submit a second contact form, since entity + id should be unique. uhm, use the session_id has id? Sounds ugly. But perhaps the only way out.
#8
This has been committed as part of #674230: Broken mass-reporting, session storage, node title mapping, watchdog messages, administrative user creation form
#9
Automatically closed -- issue fixed for 2 weeks with no activity.