NOTE: This module is now a sandbox project. Please go to:
http://drupal.org/sandbox/cgmonroe/1471836
to get the latest version / report problems.
---------------------------------------------------------------------
In the spirit of giving back to the community, here is a module I've been developing for a while which incorporates a lot of things we have needed to add to client sites using notifications. Feel free to use it as is or re-factor whatever parts you want into the project.
The core part of this module is support for a bunch of Notification related Views Bulk Operations actions that allow for bulk user changes like subscription and changing user send/interval defaults. (Theoretically, you could use these as actions for Core triggers but they have not been tested that way).
In addition, there are some UI enhancements (configurable via Admin->Messaging->Notification Utils). These include being able to turn off/on the "Do not send notifications" option based on new or update modes; location of notification field set via CCK's manage fields; option for users to update all existing subscriptions to new message or interval time when the default is changed; some better "subscription" block messaging; and some other stuff.
See the attached README file for details (also in the module tarball).
What usage cases caused these?
"Event" type sites in which the sponsor(s) wants to use notifications to "push" info to users... but "waffle" on how this should work...
E.g., All users should automatically be subscribed to X... wait... only users in Role Y should have this. All users should get notified immediately... no that should be daily and digest mode. and you already have a bunch of users set up and now need to change them.
This also tries to address the "we don't want notifications for each update" problem. This module allows you to decide if the "Don't send notifications for this" option should be checked be default on new content and/or update content forms.
It also handles the problem of: "I changed my default interval/messaging method.. why am I still getting stuff the old way?" You can turn on an extra option in the user profile edit form to "Update all existing subscriptions" when the interval and/or method is changed. (and opt to have it default to checked or not)
Additionally, it helps deal with the issue of the "notifications field set" being randomly located on node forms. With this module enabled, the location can be controlled via CCK's field management (ContentType admin) or by setting a global weight. You can also define the field set's collapsed or expanded state as well.
Finally, many of our clients found the "Subscription" block wording too technical. So, you can enable a modified version that is more end user friendly.
Oh, almost forgot... we have had occasions where lots of new content is being added and we wanted to turn off all notifications... so there is an option to do this. Generally this is a case of admin turn it off... content authors do their thing... admin turns it on. It is also useful for when the sponsor call in a panic about "VIPs" being annoyed and "We need to turn it off until we can decide what to do..."
This has been tested against the 6.x-2.3 code but unless some of the core notifications functions it calls have changed, it should work on 6.x-4.x
Enjoy.
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | notifications_utils-6.x-1.1.tar_.gz | 11.42 KB | cgmonroe |
| #16 | actions_common.zip | 2.06 KB | cgmonroe |
| README.txt | 5.23 KB | cgmonroe | |
| notifications_utils-6.x-1.0.tar_.gz | 10.68 KB | cgmonroe |
Comments
Comment #1
Skidz commentedTried it on my setup and got the following error:
During view edit:
Was still able to save the view, and when I try to open it:
My goal is to create a VBO to bulk subscribe users with role x to a specific content type.
My setup:
Pressflow 6.22
Views 6.x-2.16
Notifications 6.x-4.0-beta7
Comment #2
cgmonroe commentedSigh, looks like 2.4 changed more internals than I thought. The missing function referenced exists in Notifications 6.x-2.3.
FWIW -This module uses functions in the notifications module to get form info, check rights, and some other stuff. I guess I'll have to set up a sandbox with the new version and figure out the changes.
Comment #3
Skidz commentedLet me know when you've got another version I can test. I'm on 4.0-Beta7 btw...
Comment #4
Skidz commentedI really needed this feature, so I rolled back my Messaging and Notifications to 6.x-2.3 and this module works perfectly.
Thank you ! You saved me from having to manually subscribe 350 users to forum posts...
Comment #5
Vayira commentedHi I installed this module because I urgently need the function of being able to subscribe users to content types.
It installed perfectly, I was able to evoke the action via VBO, no errors occurred, but nothing happened. The user I'd selected with VBO was not subscribed to the content type.
I'm working with
Notifications 6.x-2.3
Notifications Utilities 6.x-1.0
Views 6.x-2.16
Views Bulk Operations 6.x-1.12
Any suggestions?
Comment #6
Vayira commentedI've tried installing devel to see if it shows up anything, but it produces so much output that I can't work out if any of it has to do with this action.
Tried installing on a separate, fairly clean drupal, nothing doing.
Can't figure out what the problem could be if it works for other people.
VBO runs other actions no prob, so that is not the issue.
Would really like to get this working.
Comment #7
Vayira commentedBeen looking through the devel log a bit searching for things related to the user I'm trying to modify who is ID 94
All I can see is
SELECT n.* FROM drupalvayira_test_notifications n INNER JOIN drupalvayira_test_notifications_fields nf0 ON n.sid = nf0.sid WHERE (n.type = 'nodetype') AND (n.uid = 94) AND (n.conditions = 1) AND (nf0.field = 'type')There is no update statement other than the session at the end of the page.
Comment #8
cgmonroe commentedHmm, following but not getting e-mails.. sorry for the delay..
My first thought is that the specified user does not have the rights to add the specified subscription. Each user selected will be checked to see if they (not the user running the VBO operation) are allowed to add the specified subscription. I do this by calling the notifications core notifications_user_allowed function.
Unfortunately the VBO structure does not allow for per operation status messages. (But I have an issue about this in... ) So, this means it is possible for subscriptions to be denied and no indication to be returned.
You might try logging onto or masquerading as the user to see if they can manually do the subscription you're trying to do with V.B.O. If they can, then let me know specifically which subscription action you're trying to do (e.g. thread, group, node type,...). and we'll go from there.
Comment #9
Skidz commentedLooks like I spoke too soon. Although I got successful messages after running the VBO, users are not subscribed. In my case, I created a custom subscription to node type forum topic. If I masquerade as a user, I can subscribe, so it's not a rights issue, but the VBO action has no effect whatsoever...
Comment #10
cgmonroe commentedHmm, I think I may be able to reproduce that here... When you created the VBO view, did you click the "batch" option? All my testing was on immediate.. and it looks like it doesn't work with batch for some reason.
Comment #11
Vayira commented@cgmonroe thanks for your reply. I'd figured out that about them needing their own rights to subscribe, but just in case I ran through it all as you said.
When I am the user concerned I can add the content type, but when I use VBO as an admin nothing happens & there are no errors.
I have selected Invoke them directly and not Use Batch API
Any more info I can give to help you see what is going on? Looks like @Skidz has the same problem.
Comment #12
Skidz commentedI'm using immediate processing as well. Here's an export of my view:
Comment #13
Vayira commentedJust out of interest I tried notifications_utils_unsubscribe_content_type_action
instead of notifications_utils_subscribe_content_type_action
That does work. I can unsubscribe the user. So this means the prob is with subscribe.
Looking at your code for unsubscribe I see
But subscribe only has
I can't actually understand this, but it does seem to be much simpler.
I'd be very interested in helping to get this to work.
Comment #14
cgmonroe commentedJust to cover all bases... I assume that you know that if the user has an existing subscription, it won't be changed unless you've checked the "replace existing subscriptions..." option at the bottom. This is so you can leave people who have already subscribed and just add new follks.
But I don't think that's the reason.... I suspect there is something going on with the core notifications check code... at least in batch mode on my site. One difference between the subscribe and unsubscribe is that the subscribe actions checks rights... unsubscribe just assumes that you have them ('cause you created the subscription)...
FYI - The form functions are just gathering the info entered after you press the execute button. The actual subscription work is in the "_action" functions (last one in the action include file). A lot of that code was basically the same across types, so often it call a function in the actions_common.inc file.
I'll see if I can figure what's going on with my batch execution not working... that may point the way. I can't seem to make it fail here in immediate mode.
Comment #15
Vayira commentednone of the users have existing subscriptions, but I've tried both with & without "replace existing subscriptions"
Is your setup identical to mine?
Notifications 6.x-2.3
Notifications Utilities 6.x-1.0
Views 6.x-2.16
Views Bulk Operations 6.x-1.12
Comment #16
cgmonroe commentedAfter a long debugging session, I finally think I figured it out... the problem is in the way I was calling the notification_user_allowed function. Apparently, there are two types of Subscription object formats... the one you get from the "add a subscription" forms and the one you get if the subscription has been retrieved from the database. So, one of the tests for user rights was failing with some forms of the form based version.
I've written some new code to convert to the format the test expects and it looks like this will solve the problem. Attached is some new code that hopefully will fix this for *MOST* of the subscription types. Can one of you (or both) try it on your sites?
Just DL the attachment, unzip the single file in it (actions_common.inc.), then replace the old file with this. (it's located in the actions subdirectory).
If this fixes the problem for content type subscriptions, then I'll go through the other actions and convert them to use this new code and post a new module version.
TIA
Comment #17
Skidz commented#16 works ! I was able to bulk subscribe my users to different content types without any issues. Let me know if you need any further testing.
Comment #18
Skidz commentedHold the phone ! I think we've got another issue here: If I bulk subscribe users to say content type 'Forum post', and then use the tool again and bulk subscribe the same users to another content type, the previous subscription is removed and only the last subscription remains...
Comment #19
Skidz commentedI did a bit of further testing tonight. Once I've bulk subscribed a user to a content type. If I try to bulk subscribe them to an additional content type, it doesn't work. If I don't tick the 'Replace existing subscriptions with these settings.', nothing happens. If I do tick it, then the new content type subscription replaces the one that was there previously. The tool doesn't allow me to choose multiple content types either, which would be a nice feature.
Now for the good news: I can bulk subscribe users to as many terms as I want, so that part works fine (although I hadn't tested it before the updated code, so perhaps that worked all along). Here again, it would be nice to be able to select multiple terms at once.
Time to hit the sack. Tomorrow's another day... :-)
Comment #20
cgmonroe commentedThe content bug is actually easy... there was a typo in the code... note to self, TEST, TEST, TEST after refactoring the code...lol
Can you make the following change to the subscribe_content_type.action.inc file and double check I've fixed it. At the bottom of this file (appx line 65), there is some code in the notifications_utils_subscribe_content_type_action function (at the bottom, approx Line #65) that currently says:
and should say:
The middle line is the only part that changes. FYI - The "condition" is part of the filter used to search for existing subscriptions. The typo was causing since the 'type' part was getting set to null. Which meant get ALL subscriptions to content types... and the forum posting type was first. The change will make search correctly for existing subscriptions.
Re: Multiple Taxonomies
That actually needs to be requested from the full Notifications module developers. This code is built to use the core functions to build/process the correct forms for each type of notification event. So, it can only offer what a normal user sees on a form.
NOTE: These manual patches are only ensuring that I know what needs to be fixed in all the code. Some of the event types will not work. The ones I know of are: OG grouptypes and threads. Once I get confirmation that the fixes work, I'll going thru all the code making sure the correction are made for all types.
Comment #21
Vayira commentedCongratulations!
By changing both those files I now have the functionality I was looking for. I can subscribe / unsubcribe users to content types with VBO.
That was the only action I was planning to use, so I haven't actually tested anything else.
I'll carry on testing a bit more just to make sure there are no unusual cases.
Thanks for your work.
Comment #22
Skidz commentedI'll test it tonite.
Comment #23
Skidz commentedSorry for the delay. Was called out of town for a couple days. Just did my tests. Everything now seems to work as it's supposed to. My tests aren't necessarily exhaustive, mind you. I am working on a live site here... ;-)
Comment #24
cgmonroe commentedAttached is version 1.1 with the user access and content-type bugs fixed across all actions. Thanks for the testing and helping find them.
I've also added a "Verbose" option to the subscribe actions. If this is checked, a Drupal "info" message will be created if a user gets "skipped" for some reason, e.g., permission failure, existing subscription and overwrite not checked, and the like. Not that this might create a lot of output if you do a large number of folks who get skipped.
Comment #25
Skidz commentedI have a question regarding one the other options added by this module:
By default, all of my users are getting notifications for all updates/comments for any content they're subscribed to. I want to make it so that they only get notified of new content, and notifications for updates or comments only if they've updated/commented on that content themselves, or are the author of the initial content. This is typically the kind of notifications setup by default for forums like smf or ipb. I just can't seem to find the right settings for it to work that way for me. I thought that by unticking the checkbox 'Send notifications for updated nodes/comments' that would be the behaviour. Are there additional steps I need to take ?
Comment #26
cgmonroe commentedHey, just getting back from xmas holiday...
Sounds like you have it set up correctly in the admin/messaging/utils page... what might be missing that users will also need the "Skip Notifications" permission to do this.
Without this permission, the option to disable notifications will not be on the add/edit forms.
If you do have this set but the form is not being alter, it might be a problem of the module "weight" not being set on install. Check your system table to see what weight the notification_utils module has... it should something like 2000 (If I remember right)... at least higher than the Notifications* modules. This ensures that the form info added by notifications is there to be modified.
As to the other settings, I think most of that can be done via the normal notification options, e.g. autosubscribe defaults, etc.
Comment #27
Skidz commentedI've checked everything you've mentioned above. Users have the 'Skip Notifications' permission, and notification_utils has a weight of 2000 in the system table (all other notifications modules have a weight of 0, except for notifications_ananymous, which is set to 200, and notifications_content, which is set to 100).
I don't see any options in the forms allowing users to subscribe only to new content. If for example, a user creates a subscription to term 'xyz', which happens to be a forum, they will receive a notification when a new topic is created in forum xyz, as well as notification for any updates or comments to that topic. There is no option in the forms to exclude these updates and/or comments.
Comment #28
cgmonroe commentedOK, I see the misunderstanding here.. This doesn't supply any new subscription types.. it merely controls the edit/create node/comment form defaults.
With Skip Notifications enabled, when a user creates or edits a node/comment, they will have a "Notifications" fieldset on the form. This will contain a check box with the label: "Do not send notifications for this update". If this is checked, then notifications will not go out when the node/comment is saved
By default, this option is always unchecked. This module allows you to control the state of that check box for new and update content.
Users can still opt to change this options if they want to. E.g. I'm not just doing a spelling fix but changing this node to point to a new release.
So, there is no "subscribe to new content of type" option. Instead this is simulated by setting the "Do not send notifications" option on update to be checked by default. Unless the editing user changes this, people only get notifications of new content of the content types they have subscribed to.
Note that this module also lets you move the location of the fieldset (default weight or in content type field layout) and collapse it by default to make it not so tempting for folks to change.
Comment #29
Skidz commentedOk. I get it. However, in my case, the 'Do not send notifications' checkbox is always un-checked, regardless of what options I chose in the utils module.
After doing a fair bit of research, seems version 4 has much more granularity. However, after testing it in my dev environment, I discovered that it doesn't play nice with existing subscriptions created under v 2. This would require me to flush all existing subscriptions and start from scratch, without the possibility of batch subscribing users.
Looks like I'm screwed either way... :-|
Comment #30
cgmonroe commentedThe code to do this is fairly straight forward form alter stuff. I wonder if another module is changing the forms and it can't find the item to change.
Some questions that might help debug this:
1) Does the "Notifications" fieldset appear inside another fieldset or on a tab? The code may not be finding what it needs to modified if a module is "embedding" it insides a fieldset or tree.
2) Can you force the notifications fieldset to be collapsed using the admin options? If this works, then the test to find the notifications section on the form is working...
3) If #2 works, can you uncheck both the send notifications settings in the admin screen and then test if the Notifications option is checked in any of the 4 options, i.e: new node; edit node; new comment; edit comment. This might narrow the problem area down.
4) If you are comfortable doing some coding, it would be nice to see the devel module's dpm() output of the form array. E.g., add in a dpm($form); statement at the top of the "notifications_utils_form_alter" function. This would let me see where your site is putting the notifications fieldset in the form structure.
Comment #31
Skidz commentedOk. After messing around with the options, here's the behaviour I'm encountering:
If I un-check 'Send notifications for new nodes/comments.', the 'Do not send notifications for this update.' checkbox is checked for any new content or comments. This is of no help to me, because in this condition, no notifications go out at all. Furthermore, with the 'Do not send notifications for this update.' checkbox checked, people subscribed to threads are not getting notified of new comments.
This is just getting more and more frustrating every day. I have 350 users pissed off with me because they either get flooded with notifications they don't want, or get none at all... I really need to find a workable solution to this problem. Fast !
Comment #32
Skidz commentedSorry for the ranting. To answer your questions:
1) The notifications fieldset appears normally. I can change it's weight and move it around the forms with the utils module.
2) Yes.
3) Yes. Everything works as designed. As mentioned above, the design doesn't fit my requirements. Every comment to a node is a new comment. Not much point in blocking updates to comments...
4) Not much point, as everything seems to be working as designed...
Comment #32.0
cgmonroe commentedAdding info about sandbox project
Comment #33
cgmonroe commentedIn case you missed the change to the main posting....
Comment #33.0
cgmonroe commentedSigh typo