I have been tracking an issue with notifications on tasks.
Notifications work for new users and some existing users, but sometimes when users (or an admin) start changing their settings on the user Notification page the Notifier that is passed to the message_subscribe_send_message() is no longer valid or is not set (eventhough there is an option selected for the space) and then no notification is sent because the function thinks the user opted out from receiving notifications or the value passed is wrong.
Sometimes this triggers a warning error when the site try to send notifications like: Warning: Invalid argument supplied for foreach() in message_subscribe_send_message() (line 140 of /.../profiles/openatrium/modules/contrib/message_subscribe/message_subscribe.module). And in some cases this goes silent with no error and no notification.
To reproduce the issue.
Create a new user or with an existing user, add this user to a space, create a task and include it on the notifications and test that it can receive them, do not assign the task to the user, go to the Notification settings for the user (user/uid/settings, change uid with the user id) and save the settings on that page this can be done without doing any change on that page, add a comment on the task to trigger the send of notifications (the user will stop receiving notifications).
If someone has a problem with notifications and want to know if they have this issue here are the steps they can do to determine that.
-Enable the devel module
-Add dpm($values); on line 138 of /profiles/openatrium/modules/contrib/message_subscribe/message_subscribe.module
( below this line $values += array('notifiers' => array()); )
-Add a reply to a task where notifications are not being sent and check that for each user $values['notifiers'] is an array and that is not empty.
If the issue is confirmed the issue could be on the profiles/openatrium/modules/contrib/oa_core/modules/oa_messages/ module.
Attached an screenshot of the output of the devel module that shows the issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | oa_core-notification-settings-2422131-5.patch | 1.71 KB | mpotter |
| notifiers-issue.png | 42.76 KB | capmex |
Comments
Comment #1
mpotter commentedAre you logged in as the new user when you change their /user/uid/settings or are you trying to change the settings of a different user using the site-admin account? That notification setting page was meant to only be used by the user themselves, so maybe there is a problem saving it when you try to change the settings for a different user?
Try logging into that user and go into their settings and try setting the Email method for that space and save it and see if that makes it start working again.
Comment #2
mpotter commentedComment #3
capmex commentedThanks for your response mpotter.
I did several tests login with the user accounts and setting the email method for the space.
Here are my findings.
This is how the system works out of the box. When a new user is created and added to spaces it receives them without any problem.
The value of the array passed to message_subscribe_send_message() in $values['notifiers'] is [0] => 'oa_email' in all subscribed spaces. Note the numeric key on the array.
Now if the user (or an admin) goes to the Notification settings and submits that page the value is changed to ['oa_email'] => 'oa_email' (the key is a string now) in all subscribed spaces. Notifications continue to work on the subscribed spaces, but after that when adding the user to other spaces the value on the new spaces for $values['notifiers'] is an empty array and the user does not receive notifications from them, it continues receiving notifications on the previously subscribed spaces. Going to the Notification settings page and submitting the page sets the value on these new spaces to ['oa_email'] => 'oa_email' and then it starts receiving notifications, the issue when the user is added to other new spaces remains and does not receive notifications.
So once the Notification settings page is submitted the user will not receive notifications for other spaces he/she is added.
Another issue I spot on the Notification settings page, that is part of this bug report, is that when bulk updating the notification methods using the "Set Spaces Preferences" -> Choose a notification method (can be any) then select the spaces (one, all or several) and click on 'Apply'. On the logs a PHP notice appears for each space:
Location http://.../system/ajax
Referrer http://.../user/50/settings
Message Notice: Undefined variable: default_methods in oa_messages_build_message_notifications_table() (line 262 of /.../www/profiles/openatrium/modules/contrib/oa_core/modules/oa_messages/oa_messages.admin.inc).
Then if you click 'Save configuration' the array is changed on $values['notifiers'] to a string 'oa_message' and this is when no notification is received and a PHP Warning appears on the logs about the invalid argument supplied to the message_subscribe_send_message() function.
Notifications is one of the most important features of openatrium. If someone else can confirm the above issues I am interested on further investigating them and testing patches or working on a patch.
Comment #4
ashutoshsngh commentedFacing similar issue related to notification.After creating any new content or commenting on any content unable to recieve email.After some testing found out that notifier array is empty.
Comment #5
capmex commented@ashutoshsngh thanks for testing this bug.
@mpotter I did more tests on a new installation of openatrium and I was able to reproduce the issue consistently.
Comment #6
mpotter commentedYep, I seem them also and am in the middle of working on it. Thanks for the detailed info on reproducing it.
Comment #7
mpotter commentedcapmex: can you try the attached patch? I think it fixes the notifications to work properly regardless of how the settings are keyed.
Comment #8
capmex commented@mpotter
Thanks, I tested the patch and it fixes the issue with notifications when adding the user to new spaces.
Is necessary to submit the Notifications settings page before the fix takes effect on existing users that already had the problem.
The issue with bulk updating notification methods remains, maybe is best if a new issue is created for it.
Comment #9
mpotter commentedYes, create a new issue for the bulk updating. Only one problem per issue please.
It shouldn't be necessary to resubmit the notification settings. At least I didn't need to here. The new code works regardless of if the key is [0] or [oa_email].
Comment #10
capmex commentedI confirm that is not necessary to resubmit the notification settings for this patch to work. The only case I could spot is when the user bulk updated their notification methods and submitted the form and ended with a string instead of an array which is the other issue reported and that will have a separate bug report.
Comment #11
mpotter commentedOK, this patch was committed to oa_core.
Comment #12
mpotter commentedActually also just found the bulk change issue. It didn't actually cause anything to not work, was just putting an error in the log files. Just committed the fix for this also in 1536a6e, so you don't need the new ticket.