mySQL query to subscribe all current users?

The exact query would depend on who you want subscribed and how (to all posts, to posts of certain node types, etc.).

What follows is not what you requested, but could equally be documented somewhere. The following script ensures that every one is subscribed to nodes they have posted, and to nodes where they have commented:

update subscriptions by node authors:

$result = db_query('SELECT * FROM {node} WHERE uid != 1');

while (
$node = db_fetch_object($result)) {
  $result2 = db_query("SELECT * FROM {subscriptions} WHERE module = 'node' AND field = 'nid' AND value = %d AND recipient_uid = %d", $node->nid, $node->uid);
  if (!mysql_num_rows($result2)) {
    db_query("INSERT INTO {subscriptions} (module, field, value, recipient_uid, send_interval, author_uid, send_updates, send_comments)
                  VALUES ('node', 'nid', %d, %d, 1, -1, 1, 1)", $node->nid, $node->uid);
  }
}

Update subscription by comments:

$result = db_query('SELECT * FROM {comments} WHERE uid != 1');

while (
$comment = db_fetch_object($result)) {
  $result2 = db_query("SELECT * FROM {subscriptions} WHERE module = 'node' AND field = 'nid' AND value = %d AND recipient_uid = %d", $comment->nid, $comment->uid);
  if (!mysql_num_rows($result2)) {
    db_query("INSERT INTO {subscriptions} (module, field, value, recipient_uid, send_interval, author_uid, send_updates, send_comments)
                  VALUES ('node', 'nid', %d, %d, 1, -1, 1, 1)", $comment->nid, $comment->uid);
  }
}

@Ashford: Go to admin/settings/subscriptions/userdefaults to set your preferred default interval.

Create a subscription and then look inside the {subscriptions} table to see what the corresponding entry looks like. Create more of those for your users.

@beginner: Iterating over all nodes or comments has the potential to time out, leaving the database in an indetermined state. An operation as you suggest should use a single SELECT with a JOIN, so that it can be restarted and will pick up where it left off.

I am looking to subscribe all users of a certain role to a Category (specific Forums) defined on the User defaults settings. With the Custom subscriptions module, this is possible for the Notifications, but not for the Subscriptions module. Is there a way to do it?

No, see above.

I don't understand. It *is* possible using Notifications, so why it isn't with your module?

No such functionality is implemented. If you want to implement it, you're welcome to do so, in a separate add-on module. I will help by answering specific questions and reviewing your code.

You might want to look through the issues queue for previous issues where this has been discussed.

I had a pretty empty subscriptions table and rand the following two queries to set it up for all my users - mine is a pretty unique case but this worked for me:

INSERT INTO subscriptions (recipient_uid)
SELECT users.uid
FROM users

UPDATE subscriptions
SET module='node', field='type', value='announcement', send_interval=86400, author_uid=-1, send_updates=1, send_comments=0

This seems like it would be trivial to add to the plugin. I am not a mysql guru, it just seems like it would be pretty basic to just apply a basic setting to all users of a role.

We have a patch in #1249502: Bulk subscribe/unsubscribe operations that would let you do this easily through the GUI, but no one cares enough to test it...

I wish I found that sooner, I would have been glad to test it.

There will be a D7 version of the patch, so it's not too late...

I just used the D6 version of the patch to force-subscribe 420 users of a certain role to a specific Content Type. Worked well - only downside is that you have to navigate through a few screens - but it does the job.

A couple of notes I made testing this (don't mean to complain - just to give you some detailed feedback):

• I ended up running some db queries in an adjacent shell to see which recipient_uids were added / demo-ed (and looked at totals) as I was doing bulk subscribes and unsubscribes. For someone w/o such direct db access it would be nice if they could generate lists via the Drupal GUI: showing how many/which users are now subscribed to what.
• too bad there are only 50 users in /admin/user/user/list - that increases the likelihood of errors - as it means you have to do this multiple times if you have more than 50 users. It was only 9 sets in my case - so I wasn't terribly motivated to find a way to increase this limit of 50 users per screen. Obviously, this is not specific to subscriptions module - any bulk operation via /user/user/list is limited by this.
• when running some mini bulk updates with a limited number of users who had already subscribed to this Content Type I found that for each of them an extra row was added to the {subscriptions} table. I'm not sure if that would translate into 2 outgoing notifications - but I ended up deciding to do a bulk unsubscribe -> followed by a bulk (re) subscribe.
• it would have been sweet if the subscribe vs unsubscribe could be a form option in the /userdefaults/bulk form (instead of in the user/user/list for update options). As you may want to unsubscribe them from one Topic and subscribe them to another. If you have a user list with more than 50 users going back and forth a lot means very carefully re-selecting the right pager number in the /user/user/list screen as every time you go back to /user/user/list you end up on the 1st screen again.

OK, this sounds like I'm complaining - but that's not the case! It would have taken me a lot longer had I not found your -dev version. Thanks a bunch!

@KarinG:

That's very useful feedback, but — could I ask you to put it into a new issue?

"closed (duplicate)" issues are dead ends that should remain dead, because the action has moved elsewhere.

"closed (fixed)" issues should usually remain closed as well, because they achieved their goal (and are typically referenced in a CHANGELOG.txt item). Possible reasons for reopening such an issue could be major bugs surfacing shortly after commit, or if you feel that you absolutely need the attention of all followers of the original thread to continue the discussion.

#12 is about tuning an existing feature, and it should get its own issue number, so that we can discuss it for its own worth and ultimately give it its own line in CHANGELOG.txt.

So, please, click edit, copy your input, and paste it into a new issue.

I apologize - didn't look at what it said above - just read your #11 note telling elBradford it's not too late to do some testing. Will re-organize things shortly.