In Liferay 5.0.0+ we have added a new feature: Announcements/Alerts.

Announcements/Alerts are two portlets which can be used to broadcast some message to a list of users within a known scope. Essentially they provide a mass messaging engine you'd tend to think of as a "news letter" or one-way messaging.

They provide the following features:

1. Configurable, unlimited number of Announcement Types through portal.properties (add locatized type names via Liferay's resource bundle extension mechanism).
2. Delivery to known scopes, called Delivery Scope, including:
   
   1. Individual User (API only)
   2. Role
   3. User Group
   4. Community
   5. Organization
3. Delivery Mechanisms include Email, SMS, and Website. (Website delivery is acheived simply by adding the portlet to any page accessible to the user. The content of the portlet is allways sensitive to the viewing user.)
4. Scheduled delivery. Each entry has a Display and Expiration Date. The entry won't be delivered until Display Date is <= now. Expiration Date is used primarily for the "Website" delivery mechanism.
5. Read Tracking. Website delivery tracks timestamped read status per user, per entry.
6. Subscription Control per user, per Announcement Type. A user determines which Delivery Mechanism to use for each individual Announcement Type. See the My Account page.
7. Broadcast Control of announcements. Broadcasting Announcements is not a permission which should be granted lightly. As such, a user must first be granted Add Entry permission on the portlet to access the Announcement management functions. Secondly, a user must have Assign Member permission on a given scope in order to be able to broadcast an Announcement/Alert to that scope.

i.e. a Community Owner is not, by default, granted permission to broadcast Announcements or Alerts to their own Community. The Portal Admin must first has to grant them Add Entry permission on the portlet. Only then would they have all the permissions required (they would already have Assign Member as a function of being the owner) to broacast to their own Community. This is to prevent abuse of portal resources and prevent needless spamming of portal users.

Via the service API we now have a means of enabling event based messaging to individual users (or any delivery scope) without having to explicitly write new delivery services or functions.

There are still a few features that I'd like to see added to this portlet, but I think we now have a good base to build on.