|Version 6 (modified by ixokai, 7 years ago) (diff)|
Flexible notifications for Trac
The AnnouncerPlugin is meant to provide an extensible, user-customizable notification system that can be used to completely replace Trac's default notifications.
At the very least, it will allow users to receive notices about attachments, and to opt-out from receiving messages due to the always_notify_(owner|reporter|updater) options.
The full system (in the not-too-distant-future) will allow users to 'subscribe' to certain events by specifying simple yet powerful rules, such as asking to receive an announcement for any change that involves a ticket with a priority greater then 'high'. Later, a 'watch' feature is intended to replace CC usage, and allow watching of wiki-pages, and then to enable other plug-ins to provide new means for registering messages that users can subscribe to.
The AnnouncerPlugin is meant to be agnostic to what is being watched; where you should send something (email, IRC, jabber, ...), and what format it should look at. All in good time.
I've gone over the various tickets on t.e.o related to notification, and have summarized them at AnnouncerPlugin/Concerns for reference to keep in mind while developing the system.
Users won't be interested in this; but developers might-- skip if you just want to use the plugin :)
Announcer is not meant to just scratch a particular itch of wanting to hear about a certain kind of thing, or have a message be sent in a certain format. It's meant to be a comprehensive and extensible notification architecture that will allow far greater control of notification delivery to users, and also make it very easy for developers (me, you, anyone!) to modify how it works.
Announcer is itself a plug-in, but it will be able to be enhanced by other plug-ins should anyone want to. As such it has a number of places where its existing behavior can be added to:
- Producers: These initiate an event; the core Announcer producers are almost all implementations of I*ChangeListener interfaces, such as ITicketChangeListener, IAttachmentChangeListener, and IWikiChangeListener. When they receive events across these various interfaces, they package them into an event and (in particular) classify each event as a "realm" and "category". For example, "ticket, created", "ticket, changed", "ticket, deleted", "ticket, attachment added", etc.
- Subscribers: These are responsible for discovering who is interested about hearing an event. Every subscriber registers itself as willing to handle subscriptions for a particular realm and/or category, and from there it checks to see what users may be interested in an event. The subscriber returns the user who is interested about the event and what method they're interested in hearing about it via-- e.g., email, IRC, IM, or whatever.
- Formatters: Once it has been decided that this particular user is interested in hearing about this event, a formatter is invoked to transform that event into an actual message. Plain text, HTML, oneliner, are all example formatters. If someone would like the ticket change email to always display certain key properties even if not changed, all that's needed is a new formatter to accomplish that.
- Distributors: Finally, the Distributor is the component that actually -sends- the message. Each one generally transmits via one type of communication channel; email, IRC, AIM, and suchlike.
- Resolvers: The purpose of a resolver is to turn a username into an address. For certain corporate sites, a component to simply append "@example.com" to the authenticated trac username will be sufficient. The default resolver will simply use whatever email address the authenticated person has set in trac. Others may be more complicated and query an external resource to determine where to send "fubarbaz"'s emails.
- Preferences: Various components may change their behavior based on user-preferences; does the user prefer HTML or plain-text? does the user not want to get messages when they update tickets? Etc. As each of these components is optional, and others may add new ones at a whim, how to manage the preferences was something of a problem. Each component could add its own preference panel, but that would litter up the interface a lot. Instead, Announcer provides its own preference interface that behaves the same way as IPreferencePanelProvider, except instead of providing an entire panel, it provides only a single "box". All the boxes are rendered together.
This code is ALPHA at present, and NOT suitable for general use.
If you have any issues, create a new ticket.
Download the zipped source from here. Note: Announcer isn't quite available yet-- re-factoring a bit then I'll post the alpha version up.
Initially(very soon now), it'll simply be a drop-in replacement for the default notifications, extending them to include attachment additions and deletions, and allowing users to opt-out from receiving notices normally sent because of the always_notify_* options.
- Groups-Prefs.jpg (19.7 KB) - added by ixokai 7 years ago.
- WatchThis.png (3.4 KB) - added by ixokai 7 years ago.
- HtmlEmail.jpg (30.8 KB) - added by ixokai 7 years ago.
- GeneralWiki.png (7.4 KB) - added by ixokai 7 years ago.
(932 bytes) -
added by doki_pen 6 years ago.
Allow mail to be sent with no username/password
- TicketNotificationPreferences.png (6.7 KB) - added by rjollos 4 years ago.
Download all attachments as: .zip