Development Seed Blog
Keeping People Posted: Notifications and Messaging
Two New Frameworks to Give You More Options
Two New Frameworks to Give You More Options
Do you want a nice Ajax UI that lets users subscribe to comments by a given user, but only for nodes of a given content type and that have a certain tag assigned, oh, and only for comments posted on Friday? Do you also want these notifications sent to you printed on nice postcards?
Then you should check out the Notifications Framework. Nope, it doesn't do all that - yet :-) - but you won't have to write it all from scratch. You'll only need to write the UI plug-in, a short module defining the parameters for this subscription type, and the 'print-and-send-to-the-post-office' module, which I think will be the most difficult one. Hey, and if you contribute back the 'print-and-send-to-the-post-office' module, I'll be able to use it with my 'happy-birthday' plugín to send birthday postcards to the users of my website!
Here's a look at the Notifications Framework in Drupal:
And here's how it looks in use on our intranet:
The key features of the Notifications Framework are
- Event and message queueing that's fully scalable and configurable
- Pluggable event types. Some plug-ins included for node and comments, but more may be defined
- Pluggable subscription types. Currently included: thread (node), author (user), content type, tag, and group (og)
- Mixed subscription types. The engine supports any combination and any number of conditions for defining a user subscription of author x, content x, type x, tag x, and group x
- Pluggable user interface. A UI module is provided but it can be disabled and replaced by a custom UI module
- Uses token module for message composition and text replacement and therefore supports pluggable tokens
Not really planned from the start, the Messaging Framework evolved out of needs we identified while building the Notifications Framework. We wanted Notifications to send emails to users, SMSs, and then also IM notifications. But really, all this is just sending messages to people. Doesn't it make sense to just send "messages'" to users and then let them decide how they want them delivered? We thought so, and that's what the Messaging Framework does.
The small messaging module we ended up with doesn't send messages by itself but does admit any kind of plug-in for different sending methods. It also has a common API for message composition and sending. One issue that came up in the process was the need to get different formatting or filtering for each channel, since these aren't the same for an email and an SMS, mostly due to the possible message length.
For message templating and token replacement, we used the Token module, which is a really powerful and extendable thing. I love these modules that don't do anything by themselves but enable any other to just plug-in and get amazing things done!
So here you go - two frameworks that may not do anything really new by themselves (just a few things), but that we think module developers and site builders will find really useful.


Comments
Nice! I've bookmarked it
Nice! I've bookmarked it http://www.searchallinone.com/Other/Keeping_People_Posted_Notifications_and_Messaging___Development_Seed-2/ :D
What is the relation to the subscriptions module
The notifications module looks very much like the subscriptions module (http://drupal.org/project/subscriptions) with exactly the same philosophy of providing a framework allowing the creation of plugins for different notification types. What do you see as the relative merits of the two modules?
Hmm. As of last month, I was
Hmm. As of last month, I was planning on working on finishing some code that moshe had started for creating email digests. I'm glad I didn't start when I planned as there seem to be several options that have come out since then. However, it seems that no option is completely finished, and so I would like to throw in with one camp and help with finishing it up. The question is: which module should I support? I would therefore be interested in any comparisons that can be made between the several modules. Also, is this module even on d.o.? Is it this one: http://drupal.org/project/notifications ?
Yes, both modules
Yes, both modules (notifications and messaging) are on d.o, see links on the blog post.
As it is stated in the documentation, this one started as a fork of the subscriptions module, though it's been completely reworked since then, mostly to meet our needs of more flexibility and escalability.
About which one to use, I suggest giving a try to all the options (there are more than two actually) and go with the one best fits your needs.
Feedback and contributions are welcomed. And if some feels like writing some good comparison, that will be interesting too. I'm sure a third-party one will be much more productive.
two more thoughts
job_queue.module has some useful logic for automatically avoiding cron timeouts. perhaps copy that or integrate with it. this will emove some admin UI for you, about 'process steps' and so on.
perhaps use mail_edit module for mail template editing.
Good idea
Added the % cron time logic in the queue processing and removed the 'steps' which you're right, was a bit confusing. About the other 'process limit' options they stay for the moment. While for small sites with little users they will be no use at all, we want this to manage high traffic ones too and allow site admins to really do some tunning here...
About mail_edit, we are not dealing only with e-mails, but with other sending methos too, and also I like better the token mechanism which IMHO alows more flexibility so I don't think that's an option here.
Thanks for the suggestions.
very nice
i took this for a trial today and i am very impressed. I was going to see if og should delegate all its subscriptions to this framework and I almost fell out of my chair when I saw that you already have an og plugin.
a few notes: - at send time, a plugin needs to verify that the notification is still valid. for example, a user might have unsubscribed from a group or the node may no longer be associated with the group which caused the notification. I assume plugins like og can intercept this at send time? this ties into the option for 'Test held posts prior to sending' - the current UI module only shows subscribe options on the node/comment form? that contrradicts the 'link' mentioned at admin/notifications/settings/content )for example). we need a subscribe link for viewers as well. for this link`, i prefer a single subscribe link which pops up a dialog showing all the available subscriptions. i know - maybe i'll write it myself :) - some ideas are not yet clear. "autosubscribe" and "simple mail" need some better descriptions IMO. - i'd love to see some fields for Views which say 'subscribe' and 'unsubscribe' for a given node. for this, my popup dialog would be essential.
OG integration is important
OG integration is important for some sites we are building so you can expect to see some developments on that side in the next future :-) Also if you miss anything about that or have any idea on how to improve the module, please let me know.
The permission checking before sending is already implemented and yes, there's a new hook_subscriptions('access'.. ) for modules to check more permissions.
About the UI part, agreed, it needs some more polishing yet, and maybe more per content type options. They'll be coming but yes, if you want to write something it will be very much welcomed :-) However, not sure which version you've tried but there are also some 'show as links' option already implemented
Ok about the descriptions, also missing help texts and tips, adding this to my to-do list.
About the views fields, not sure what you mean, won't the node links do for that?
Thanks for all the feedback
nice work
this looks like important work. just want you to know that a prior module that was part of SoC attempted to do almost exactly what you have built. it had quite similar API fro myour description. see http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/subscriptio.... those are docs i wrote when i was trying to grok it. you can poke around from there.
Hey Moshe, Thanks for the
Hey Moshe,
Thanks for the info, I've just been looking at this other module and yeah, it might have been a good starting point to build upon.
We happened to start forking the other subscriptions module though, which had more features and was up to date at that moment, and then ended up reworking it completely.
Post new comment