Skip to content

Correspondence Technologies

Sections
Personal tools
You are here: Home » Software » SfIndex Demo » collective - CMFNotification

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.

 

Powered by Plone

This site conforms to the following standards: