Set all users as subscribed to notifications from groups

I just had the same problem, although I'm running the current stable release (so not sure if this has been fixed in the latest RC or in dev). I've created a script (attached here) that fixes the issue. You can place this in your install's document root (same place where cron.php lives) and then run it from your webserver.

Here's a description of the problem and the solution from the comment header:

/**
* @file
* Fixes situation described in http://drupal.org/node/460518 where users who
* did not have og_notifications enabled in Drupal 5.x upgrade to Drupal 6.x,
* but find that group notifications are not autosubscribed any longer.
*
* The problem is (I think) that since notifications were never enabled in D5,
* the upgrade process does not run the crucial procedure
* og_notifications_og_upgrade() in
*
* og/modules/og_notifications/og_notifications.install
*
* This script takes into account the other changes that *have* been made to the
* og_notifications schema/data, and then runs the aspects of the above
* procedure that are necessary to autosubscribe these users.
*
* The script assumes in the SELECT query below that the site's overall
* autosubscribe policy is to autosubscribe users to groups. If it is not,
* replace the query with the following: SELECT ou.nid, ou.uid FROM {og_uid} ou,
* {og_notifications} os WHERE ou.uid = os.uid AND os.autosubscribe = 1
*/

@Zen - any thoughts on this?

I have a related "feature request". I have been trying to produce views that show who has notifications for each group, rather than just membership. I want to see this both per user and per group (for use by admins - users can already see their own). I think this would help riverfr0zen and possibly seaneffel.

I have not yet made this work, partly because I have not mastered relationships in views, but also there is an error in the OG view link up - notifications interval field handler doesn't work.

Still using:
Drupal 6.12
Messaging 6.x-2.0
Notifications 6.x-2.0
Organic groups 6.x-2.x-dev (2009-May-14)
Views 6.x-2.6

(so the error may have been fixed)

There might be some use in combining this with the present functions on page admin/messaging/subscriptions/admin

@riverfr0zen

thanks for this script. very helpful. i have had loads of headaches with og notifications/messaging/notifications modules since upgrading to D6, and your script was a nice respite...thanks for posting!

It seems like a good idea to update the og_notifications table with the new global policy of being subscribed to new groups.

Overall, this looks like a good approach that seems to create the proper subscriptions on a test update from Drupal 5.

This probably makes sense as an administrative button, rather than being done automatically during an upgrade.

Please provide more information on your installations. Did you have og_n installed at some point, then disable it, upgrade and re-enable it? Did you use any of the D5 OG betas at any point?, etc.

-K

anyway, my script apparently fixes it for most people. zen can take a little break.

(i was being funny)

This script seemed to work alright for me, but I didn't actually see the notifications going out. Everyone seemed to be subscribed, but the entries in the {notifications_fields} seemed all wrong.

However, since my upgrade I've been having all kinds of bugs, so I can't say the script doesn't work at all. I also think there are just so many ways to configure the Notifications, it must be tough to write one script that will do everything.

I noticed that the includes at the top of the script didn't list everything that the og_notifications module depends on - maybe this is why my subscriptions only worked half-way?

i.e. from the og_notifications.info file:

dependencies[] = og
dependencies[] = notifications
dependencies[] = notifications_content
dependencies[] = notifications_lite
dependencies[] = messaging
dependencies[] = token

and from the script:

<?php
  drupal_load('module', 'og_notifications');
  drupal_load('module', 'notifications');
  drupal_load('module', 'token');
  drupal_load('module', 'messaging');
?>

@Zen #6: Finally got some time to look at revisions of my install. I believe in my case, the install was using the 5.x-3.x-dev release dated 2007-08-11.

Prior to the D6 upgrade, the module was disabled before updating to the latest D5. It was then re-enabled, and updated to the 5.x-8.0 release dated 2009-01-03 (which was the latest stable release at the time). update.php was run after the module update.

I think it's probably due to the 5.x.3.x-dev release not having a separate og_notifications module, hence the specific method mentioned above, which was in og_notifications.install, never ran (og_notifications was never enabled). Probably would be good to have an update method at wherever in the version tree the og_notifications module was introduced that (a) enables the og_notifications module, and (b) performs the operation in the script above based on the old email subscription settings.

Not sure if that already happens somewhere, but somehow it seems to have come amiss in the process of upgrading from D5 to D6 for me (and it looks like some others). Anyway, hope this helps!

@liberatr: Yeah, the configuration of notifications is quite complicated, so you'll need to determine at what point the issue is occuring.

I doubt that the issue is not including those other modules, since the methods being used are only defined in those modules that are being loaded. (The script was pretty much lifted word-for-word from an update function in og_notifications.install, with minor changes). In any case, if that was the problem you would likely be getting a fatal error.

If you could give more info on why you think the {notifications_fields} entries are wrong, that would be helpful. Perhaps paste some rows here. Also you could paste the corresponding rows (linked by sid) from the {notifications} table. Also, after trying to trigger a group notification (e.g. by posting a node of a type that is configured to generate notifications for groups), try seeing if the corresponding entries are created in the {notifications_queue} table. If they are, then there may be some problem in the queue processing stage.

I've encountered a similar problem, but on the D5 line only in upgrading from OG circa July 2008 to the current D5 OGv8.1.

// $Id: og.module,v 1.298.2.195 2008/07/02 19:57:44 weitzman Exp $

What I eventually concluded was that the prior OG essentially supported implicit and explicit subscriptions to groups. The explicit subscriptions were captured in the og_uid table, showing who had signed up for notifications in which groups. The implicit was recorded in og_uid_global, where the user's default setting lived.

Many of the users on the site I was working with had no per group subscription set in og_uid - but they did have their og_uid_global.og_email value set to 1

og_mail() has the following query, that obeys both the implicit and explicit subscriptions

    // tricky query here. mysql returns NULL in the case of NULL != 0 so i rework this for 2 positive statements about og_email field
    // ORDER BY favors newer groups to help them get ramped up. Thus, they are perceived as active.
    $sql = "SELECT u.mail, ou.nid AS gid, n.title AS group_name, n.uid AS group_uid, u.name AS group_owner, oug.og_email 
            FROM {og_uid} ou INNER JOIN {users} u ON ou.uid=u.uid 
            INNER JOIN {og_uid_global} oug ON ou.uid=oug.uid 
            INNER JOIN {node} n ON ou.nid=n.nid 
            WHERE ou.nid IN ($groups) AND (
              (oug.og_email = %d AND ou.mail_type=1) OR
              (oug.og_email = %d)
              ) AND u.status = 1 AND u.mail != '' AND ou.is_active = 1 
              ORDER by u.mail DESC, n.created DESC
              ";
    $result = db_query($sql, OG_NOTIFICATION_SELECTIVE, OG_NOTIFICATION_ALWAYS);

When I upgraded to OGv8.1, it correctly set the flag telling og_notifications that it needed to perform a conversion. I had never previously had og_notifications loaded.

og.install (v8.1)

function og_update_5703() {
// stuff
  // Set update flag for og_notifications.
  variable_set('og_notifications_update_required', 1);
// further stuff
}

And then in og_notifications.install, the code loops through and correctly translates all of the explicit subscriptions.

/**
 * Notifications upgrade: Based on the upgrade flag, move existing subscriptions
 * to the notifications module.
 */
function og_notifications_og_upgrade() {
  $ret = array();

  // Load notifications and dependencies.
  drupal_load('module', 'og_notifications');
  drupal_load('module', 'notifications');
  drupal_load('module', 'token');
  drupal_load('module', 'messaging');

  // Save notification subscription for each group based on og_uid.mail_type.
  $result = db_query("SELECT nid, uid FROM {og_uid} WHERE mail_type = 1");
  while ($subscription = db_fetch_object($result)) {
    // Resort to subterfuge to avoid repeat calls to user_load.
    $account = (object) array('uid' => $subscription->uid);
    og_notifications_user_subscribe($account, $subscription->nid);
  }

  // Drop field notification.
  db_query("ALTER TABLE {og} DROP notification");
  // Drop field mail_type.
  db_query("ALTER TABLE {og_uid} DROP mail_type");

  // og_email is now effectively only a boolean. Users with 
  // OG_NOTIFICATION_SELECTIVE are equivalent to those with autosubscribe turned
  // off.
  $autosubscribe = variable_get('og_notification', 1) == 1 ? 1 : 0;
  variable_set('og_notifications_autosubscribe', $autosubscribe);
  variable_del('og_notification');

  db_query("INSERT INTO {og_notifications} (uid, autosubscribe) SELECT oug.uid, oug.og_email FROM {og_uid_global} oug");
  db_query("UPDATE {og_notifications} SET autosubscribe = 0 WHERE autosubscribe = 2");

  db_query('DROP TABLE {og_uid_global}');

  variable_del('og_notifications_update_required');

  return $ret;
}

It also translates all of the implicit subscription flags into the correct setting for all NEW groups that the user joins, setting the auto-subscribe on.

But what I do not believe happens anywhere is exactly what the "fix" script higher up on this issue does. Nowhere are the implicit subscriptions driven by og_uid_global.og_email turned into a list of explicit subscriptions for the Notifications module.

Hopefully this helps the next person who wonders what happened and why the fix script on this issue solves their problem. I think it's an oversight in the og_notifications.install that only migrates the per-group explicit subscriptions.

Thanks for the script in #1. My subscriptions got into some weird state when I was setting the modules up. Some content types were subscribed in some groups but not others. Running this script corrected everything. I didn't have to remove existing subscriptions before running this script.

The script in #1 looks like just what I need but I have a multi-site configuration.

Running the script in the same directory that cron.php resides in does nothing.

Running the script in the sites/example.com directory returns errors:

Warning: include_once(./includes/bootstrap.inc): failed to open stream: No such file

Changing the line in the script:

include_once '../../includes/bootstrap.inc';

Returns a different error:

Warning: require_once(./includes/cache.inc): failed to open stream: No such file

What I need is a way to use Drush to run the bootstrap and script but I'm not sure how to do that. Any help would be greatly appreciated.

How did I get to needing this?
While doing tests on notifications 2.x and 4.x then reverting back to 2.x and having to uninstall modules to do that and re-enable them. Somewhere in the process users subscriptions to group content was lost.

Thanks

Answering my own question in #15 on how to use drush for the script in #1

Commented lines:

// include_once './includes/bootstrap.inc';
// drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

Then in the sites/example.com directory used the command:

drush scr og_notifications_fix.php

And the script runs. Now I need to comfirm what is done.

Thanks.

Thanks very much.

The script in #1 works great with drush on multi-site install using the change in comment #16 and restores the users subscriptions to group content.

A reset users subscriptions on the admin page might be helpful for admins that don't have drush access.

This version of Drupal is not supported anymore. If this is still an issue in the 8.x-1.x branch, please open a new up-to-date ticket. Closing.