Set all users as subscribed to notifications from groups
| Project: | Organic groups |
| Version: | 6.x-2.0-rc3 |
| Component: | og_notifications |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
I'm finishing an upgrade of OG from D5 to D6 and I've lost all the notifications subscription information for all users. None of my users are subscribed to notifications from their groups any more. I would like to reset them all to subscribed, but there are too many to do manually and I don't understand the database level well enough to work that magic.
I have two questions on this:
1. To solve my immediate problem, is there some magic query that you all use to set all users to subscribed for notifications from their groups at the database level? I understand that this will negate choices that users have made previously on their subscriptions, but our user base is one that won't mind this infringement on their free will. What is that query?
2. In the long run, is this the kind of feature that would be sell suited to present in the OG Notifications configuration area for admins to blindly reset user prefs on notifications? I see this question asked a lot and then not a lot of good answers to it. Could there be a check box, with the right cautionary message, to do this job?
Thanks for the help!
Sean

#1
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
*/
#2
@Zen - any thoughts on this?
#3
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
#4
@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!
#5
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.
#6
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
#7
#8
anyway, my script apparently fixes it for most people. zen can take a little break.
#9
(i was being funny)
#10
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[] = ogdependencies[] = notifications
dependencies[] = notifications_content
dependencies[] = notifications_lite
dependencies[] = messaging
dependencies[] = token
and from the script:
<?phpdrupal_load('module', 'og_notifications');
drupal_load('module', 'notifications');
drupal_load('module', 'token');
drupal_load('module', 'messaging');
?>
#11
@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!
#12
@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.