First, I am using organic groups, and yes, my normal group notifications are working fine using the dev versions of notifications and messaging. There is another feature for messaging users in OG called "broadcast" and uses notifications_lite_send as you can see below, but it results in everything always being queued in the "never" send queue, despite the user's notification settings or the default interval settings.

   case 'user broadcast':
      $destinations = is_array($uid) ? $uid : array($uid);
      foreach ($destinations as $uid) {
        notifications_lite_send($uid, $args['subject'], $args['body']);
      }
      break;

I changed the value of $send_interval manually to "Immediate" in the code shown below, and the messages were sent out as expected. Am I right in assuming there is an issue somewhere in getting the right send interval?

/**
 * Insert lite notificaition into queue
 */
function notifications_lite_queue_event($event) {
  $uid = $event->params['for-uid'];
  $account = user_load(array('uid' => $uid));
  $send_interval = notifications_user_setting('send_interval', $account);
  $send_method = notifications_user_setting('send_method', $account);
  $sql = 'INSERT INTO {notifications_queue} (uid, sid, module, eid, send_interval, send_method, cron, created, conditions) ';
  $sql .= " VALUES(%d, 0, 'notifications', %d, %d, '%s', 1,  %d, 0) ";
  db_query($sql, $uid , $event->eid, $send_interval, $send_method, time());
}
CommentFileSizeAuthor
#16 notifications_lite-module-20091210-1539.patch645 bytesAnonymous (not verified)

Comments

sansui’s picture

sansui commented
Category: support » bug

I'm not sure the best way to try and debug/test this stuff, so I just printed out the account object while on the notifications settings page on a user account and tried to identify the appropriate areas:

[data] => a:6:{s:16:"privatemsg_allow";i:1;s:28:"privatemsg_setmessage_notify";i:1;s:14:"picture_delete";i:0;s:14:"picture_upload";s:0:"";s:17:"messaging_default";s:10:"privatemsg";s:27:"notifications_send_interval";s:2:"-1";}
[privatemsg_allow] => 1 [
privatemsg_setmessage_notify] => 1
[messaging_default] => privatemsg
[notifications_send_interval] => -1

The send interval always shows up as -1 in the account, regardless of what settings are actually there. My database shows the intervals are assigned correctly - 0 for immediate sending, 3600 etc, not a single -1 in sight.

Why does it always return -1 for send interval :(

sansui’s picture

sansui commented

In notification_user_setting, I tried hardcoding the return value. Set to "-1", it doesn't complain at all, just queues everything in "never" like it's been doing. 

  if (isset($account->$field)) {
    return $account->$field;
  }

If I set it to return 0 instead of -1, it sends my message but I also see this at the top of the message:

[UNDEFINED type = digest, method = privatemsg, key = notifications-digest--]

sansui’s picture

sansui commented

Still unable to resolve this issue. The only way it can be getting that -1 value is from the default value, but I can't figure out where/when it would be getting that value since the account value is obviously defined.

jose reyero’s picture

jose reyero commented

But it seems the account value is -1 (Never)... ?

sansui’s picture

sansui commented

Right, the account value is showing up as -1, even though the account settings have been set to Immediate (0) or any other interval. There are no accounts that have -1 set for their send interval in my notifications database.

The default setting for notification in the main settings is also set to immediate, not to "never". There is no configuration or setting that should be setting the account values to -1, which is why I'm baffled.

jose reyero’s picture

jose reyero commented

You mean the user account setting to set that value is not working?

(Otherwise, it may be an old value set with some previous version..)

sansui’s picture

sansui commented

Yes. The user account settings don't change the value away from -1 no matter what they're set to. The default setting in the module also does not seem to have any impact (I changed it from never to immediate)

sansui’s picture

sansui commented

You are my last hope jose ;( Every day I try to look at this and hope I can fix it, but every time the account continues to show -1 as the send interval regardless of the actual database values.

If these values are indeed 'old values' that were set by the default (which was originally never), where is the value stored other than in the table for notifications that specifies send value?

I flush the cache regularly, so it couldn't be that I wouldn't think. Is there another table that would store this value?

jose reyero’s picture

jose reyero commented
Category: bug » support

I've just giving it a try and it seems to work. I can successfully change interval for an account and it gets into the queue table, so I'm clueless about your issue.

About the UNDEFINED message, change the digesting for 'Inmediate' send interval to none.

Anyway, if you're using these features, you should consider upgrading to 6.x instead of investing more time on 5.x

sansui’s picture

sansui commented

Doh, well thank you for trying it. I would love to use 6.x for this project, but there were essential tools needed that only work properly in 5.x

I would have thought I could work through this issue, but the account always returning the same value with no apparent cause for having that value, has left me in the fetal position. I've tried uninstalling and reinstalling these modules, creating new accounts, different roles, uninstalling other modules, and I keep coming up with the same result. I think I will give up the fight and go without the group broadcast feature

jackspiv’s picture

jackspiv commented

I have been struggling with the consequences of broadcast not working for some time now (ever since I upgraded to OG 8.0 and then downgraded the OG Notifications module back to 7.3)

I am also in the position that I cannot upgrade to 6.x (wish I could...) because other modules I depend on are not available.

I am hearing more than one thing going on in this thread.

To summarize our current data. (please add to or correct this if it is incomplete or wrong)

1) Sansui seems to be concerned primarily that Broadcast is not working.
2) Sansui prints the value -1 (associated with notifications_send_interval) while on the notifications settings page on a user account (curious how this is done ... some PhP? Where?)
3) Sansui has checked the database and finds no -1 entries associated with send interval (What variable/s and Table/s were you examining?)
4) Sansui sees no change in the printout value (-1) or the database entries regardless of the setting chosen on the user's notifications setting page.
5) Sansui flushes the cache (which cache and what command - there are many?) regularly so expects no values stored there.

Is this all correct?

5) Jose tried to change the send interval with the user's notification setting page and was simply successful.
6) Jose found that the settings value gets into the queue table appropriately.

Some Questions:

Jose - what is the actual name of the table and name of the variable that you are looking at in your database? Just to be sure it is the same one that Sansui is seeing no change in.

Jose - have you (can you) tried to generate the same printout of Notifications_send_interval that Sansui has generated and is concerned about?

Jose - *** Most fundamentally important to this discussion ... are you able to actually get email messages successfully broadcast to a group (members other than admin) using the functionality on the OG Broadcast tab? If so, what notifications settings were you using?

Jose - What user access control (permissions) settings - if any - control the broadcast functionality? Must this be set in Notifications, Messaging, or OG ... or both/all? Is this feature only usable by an sys admin, group founder/admin, or normal users?

Jose - What user access control (permissions) settings - if any - control a user's ability to receive emails broadcasted by the Broadcast functionality?

Both (Jose and Sansui) can you state your current testing configuration and versions?

OG ... version?
OG_Notifications ... version? Used? y/n
OG_Notifications_Lite ... version? Used? y/n
Notifications ... version?
Messaging ... version?

Are there any other obviously related modules that we should include in this comparison list?
Job_queue maybe? ... version? used? y/n

Thanks. There's a lot going on here for me. I'm inclined to check first to make sure that we are all on the same page...

jose reyero’s picture

jose reyero commented
Status: Active » Postponed (maintainer needs more info)

There were some issues with digesting notifications_lite messages so I've done something a bit drastic: Setting the send_interval to 0 (=Inmediate) for this kind of notifications.

Let me know whether this works better.

This will be properly handled in 6.x, that is already fixed. I don't want to spend too much time on 5.x though.

jackspiv’s picture

jackspiv commented

Jose,

Thankyou. I think this sounds good.

Just want to make sure.

1) When you say for "this" kind of notification ... do you mean notifications that are originated via the broadcast tab in OG?

2) Also, where have you made these changes? is it in a 5.x-dev package? Currently on the project page? or only in CVS?

3) If so, how does this current dev version play with OG 5.x-8.0? Has the issue at #331292: OG incompatible with notification stable release been resolved?

jose reyero’s picture

jose reyero commented
Status: Postponed (maintainer needs more info) » Fixed

@jackspiv,

1) Yes
2) For some reason, 5.x-dev versions were not being updated, it seems they are now. Anyway, I'll do a 5.x maintenance release soon
3) You tell me. That other issue will be closed when resolved I guess...

I'm closing this one since the original issue (Send interval...) is fixed. For remaining og/notifications 5.x issues please follow up here, #331292: OG incompatible with notification stable release

And anyway I strongly encourage everybody to update to 6.x ASAP.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new notifications_lite-module-20091210-1539.patch645 bytes

Here is a patch I wrote which fixed the problem for Notifications 6.x-2.1 running on postgreSQL. Not sure if it is the same for 5.x though.