Package: collective - CMFNotification
a test of SfIndex product
Sourceforge Info
| Project Name: | collective |
| Package Name: | CMFNotification |
| Files Page: | |
| Browse CVS: | http://cvs.sourceforge.net/viewcvs.py/collective/CMFNotification/ |
Package README (CVS ver. 1.1)
This is yet another Notification tool for Plone/CMF. Here's a breakdown of
what a notification solution has to do in general:
1) Provide an interface for subscribing and unsubscribing
2) Store subscription info
3) Hook into some event to trigger notification
4) Account for both folderish and documentish objects
5) Locate all subscribers for an object
6) Format a notification email
7) Send the notification email
There are two existing products that I see in the Collective. Here's what they
are doing AFAICT:
I. CMFSubscription
1) Uses a portal_tab and a pref_panel. In the TODO they suggest a
document_action and a portlet.
2) Subscription info is stored in a new "Subscription" object.
3) Hooks into document_edit using old nav_tool.
4) Only supports documents proper.
5) Searches for Subscription objects, subscriber is Subscription creator.
6) ack .. ok this product is dead -- it claims to be dependent on non-
existent product PloneNotification or PortalNotifications).
7) Moving on ...
Bottom Line: This product is out of date.
II. PortalNotifications
1) Not subscription-based; rather based on portal roles. I.e., this product
basically patches plone_workflow with email notifications for reviewers
and content authors (owners).
2) n/a
3) Steals content_status_modify.
4) Works w/ all content.
5) Based on stock Plone roles.
6) Has a Notification class which is configurable TTW
7) Uses PortalMail
Bottom Line: Some nice TTW configuration; closely related to plone_workflow.
And here's what we are doing:
III. CMFNotification
1) Portlet and pref_panel. Adding document_action would be trivial, but
that doesn't give us enough flexibility to say whether they are
explicitly or implicitly subscribed.
2) Subscription info is stored as a local_role (this is my favorite part :).
3) Hooking into an event is manual at this point. Cut/paste
notification_send to a workflow, e.g.
4) Built for folderish objs but it shouldn't be too hard to support
documentish objs.
5) Locates subscribers based on our special local role.
6) Using PortalMailTemplates.
7) We also use PortalMail.
Bottom line: We are using the tools and techniques of PortalNotifications to
solve the problem of CMFSubscription, but w/o PortalNotifications TTW
configuration functionality.