Sending out notifications not subscribed

Are you sure they are not subscribed? Do you have "autosubscribe" set to "On" by default? Could they be subscribed to a node type, rather than a node? A category? Check the subscriptions DB table for anyone who claims to have recieved an unsolicited subscription and look for their User ID. What does it say they are subscribed to?

I'd be glad to do whatever you need to pinpoint this, but my level of experience with mysql is limited to a few commands.

Well, you need to start off trying the stuff I suggested in the first post. As for mysql, don't bother dong any mysql commands - I'm suggesting you use whatever tools come with your database (like phpMyAdmin or mySQLcc or whatever is there) to just browse the table. I'm still not convinced this is a bug so much as a by-design-feature not being fully understood. I think.

Hi Dan,

I faced the same problem just today after upgrading to 4.7 and installing the 4.7 version of subscriptions module. Nearly one hundred users of my site (including me!) got content notification emails to taxonomy terms etc they had not subscribed to. I had to turn off the module in a hurry but the damage had been done by the time I noticed it. Some users reported receiving upto 70 such emails.

This was a nonprofit network, so the people were polite and I sent an apology:(

Can either of you tell me which options in the module set up you have activated? Can you list out steps by which I can duplicate the mailing of a notification to an unsubscribed user? If I can duplicate it, I can fix it.

I will give the details of user wise subscriptions tomorrow, but this basically happened after I simply installed the 4.7 module on the upgraded site (4.6.5 to 4.7) and enabled it.

While I'm waiting on somebody to get back to me with some specifics, this just occured to me: I've modifed the table structure for mySQL tables and didn't really advertise it:

DROP TABLE IF EXISTS subscriptions;
CREATE TABLE subscriptions(
sid int(10) unsigned not null,
uid int(10) unsigned not null,
stype varchar(25) not null
);

stype is now 25 characters long where it used to be 4. Not sure if that is an issue, but it might be.

Yes, it will. If you don't know how to alter the data type info directly, you can try this script:

ALTER TABLE `subscriptions` MODIFY `stype` varchar(25) NOT NULL default '';

... give or take some punctuation, depending upoin what you are using.

I'm wondering if several truncated entries were made before you did that. Maybe you want to run something like this:

DELETE FROM subscriptions WHERE stype= 'type';

'type' is an invalid stype, and might be the result of a too-short data field.

I'm not positive about this, but I still am not able to duplicate this on my system, so I'm having to guess about how yours might differ.

Another option to test:

I think this has somethng to do with pre-existing subscriptions and the "node type" subscription option. If one were to comment out the calls to the node type subscriptions, this might go away:

$strsent = $strsent . subscriptions_mailvars($nobj->type, $nobj->nid, $user->uid, 'type', $strsent);
and...
$strsent = $strsent . subscriptions_mailvars($node->type, $node->nid, $user->uid, 'type', $strsent);

To 'comment out' is to add a "//" to the front of line. e.g.

//$strsent = $strsent . subscriptions_mailvars($node->type, $node->nid, $user->uid, 'type', $strsent);

This is a new feature so you won't miss it. If this works, you need to make the menu options go away, too. I'll give you the code for that here. This will at least give us a little more time to see what we can do to get the data up to the new standard.

The column is "stype", not type.

Glad to know we can at least determine which feature is causing the problem. I've rolled the branch code back to the last known good build, but yours has a few more features the way it is. I didn't filter the menu on user (although you might have with permissions). To finish the clean up, comment out the twi sections that look like this :

		 	$items[] = array('path' => "subscriptions/type", 'title' => t('content types'),
			  'callback' => 'subscriptions_page', 'access' => user_access('maintain subscriptions'),
			  'type' => MENU_LOCAL_TASK);

and

			$items[] = array('path' => "user/$user->uid/subscriptions/type", 'title' => t('content types'),
			  'callback' => 'subscriptions_page', 'access' => user_access('maintain subscriptions'),
			  'type' => MENU_LOCAL_TASK);

I'm almost positive this is related to legacy data in the subscriptions table, but I'll see if I can prove that.

Commenting out that code seems to do the trick.

The behavior of this bug seems to be that notification e-mails are sent to everyone who has any sort of subscription active. For example if you have a single thread subscription then you are also sent all notifications for other threads, all content types and all categories. If a user does not have any subscriptions active, then they aren't effected by the bug. I have tested this on a clean install of Drupal 4.7.1 with Subscriptions 4.7 running both IIS and Apache using PHP 4.4..

Also seem to have an issue where notifications are not sent when a node is updated and there are valid subscriptions for that node. I'll log this under another bug report though.

Beauty feedback, brashquido. You have a second career in QA awaiting you. I'll see if I can fix this manana.

Dan Ziemecki

I think I got this licked. I had to change a 'd' into an 's'. Can one of you guys confirm this on your system before I roll this out to the ROTW?

The 'd' and 's' thing was probably more detail than you really needed. The fully featured and debugged subscriptions.module was attached to my previous post.

I haven't made any DB alterations Dan, and I get this error now when submitting a story regardless of wether there are any active subscriptions for that thread/category/content type or not.

Unknown column 'typestory' in 'where clause' query: SELECT u.mail, u.name, u.uid, u.language FROM users u INNER JOIN subscriptions s ON u.uid = s.uid WHERE s.stype =typestory in D:\iisroot\drupal\includes\database.mysql.inc on line 120.

sigh.

Is it only for Story nodes? I wasn't testing against that node type and didn't get that error.

Both of you appear to be getting un-enclosed strings in your query string. Don't know why I don't but I've attached another version that hard-codes the string wrappers. Works for me. Of course, so did the last one.

Is it only for Story nodes?

No, it was happening for page content type as well for me. You seem to have this issue sorted already though.

Tried the new module code, and it seems to be working fine. I seem to have stumbled upon that delayed notification issue we spoke of some time ago, but I suspect that is an environment issue. I'm going to start a fresh again as I have installed a few other modules on this test site since yesterday.

Ok, I think I've got the problem cornered now. It originally looked like that delayed send issue I had a while back, but it appears to be different.

Started again with a fresh install of 4.7.1 with subscriptions_3.module from above as the only installed contrib module using all default settings. Subscription e-mails are now sent correctly for thread and content type level subscription, but no subscription e-mails are sent for cateogry level subscriptions. The watchdog logs show nothing and nothing is coming into my test email accounts. I tested this using PHP 4.4.1 using both Apache 2.0.55 and IIS 5.1, and the behaviour is consistent across both webservers. Seems to be an issue when taxonomy subscriptions are involved?

I was unable to dupe the taxa problem, and it would not be related to the change I just made. Please submit that as a separate issue. I'll close this one and commit the code so that no one else has to deal with the unrequested notifications issue.

1 week, no follow up. Presuming closed.