Notification plugin

[wichert@…]

Currently trac only supports email notifications. For some environments it it would be very practical to use different kinds of notifications; for example to send a SMS when tickets of a specific type are files, or to notify CIA of new tickets.

It seems sensible to create an extension point for the notification infrastructure so one or more plugins can handle notifications.

[wichert@…]

Example of submitting messages to CIA from trac

[wichert@…]

I've added a patch which implements a trac-CIA connection. This implementation is quite bad since it hooks trac directly into the email notifier logic, but the xmlrpc code can easily be reused.

[Christian Boos]

Yes, a more generic infrastructure for notifications will be a big topic for 0.12.

[pookey@…]

I'd really appreciate if someone could manage to update this patch to work with 0.10.4 - my python skills are sadly lacking!

[wichert@…]

I did an improved version of that patch for 0.10 a while ago. I'll add it to this issue.

[wichert@…]

CIA for trac 0.10.4

[wichert@…]

CIA for trac 0.10.4

[davidf@…]

Also wanting to add a generic jabber notification system…. again this would make sense as a plugin

[anonymous]

We definitely need a few explanations about how to make it work. I've patched my trac, figured a few config items from code, but i can't make it work. Can someone please post instructions and a config sample? Thanks in advance.

[Emmanuel Blot]

Replying to davidf@sjsoft.com:

Also wanting to add a generic jabber notification system…. again this would make sense as a plugin

BTW, for Mac users only: I've written a ​growl notification plugin.

[wichert@…]

For reference this is the configuration we use for Plone:

[notification]
always_notify_owner = true
always_notify_reporter = true
cia_enabled = true
cia_project = Plone
cia_server = http://cia.navi.cx
smtp_always_cc = plone-collector@objectrealms.net
smtp_enabled = true
smtp_from = discard@antiloop.plone.org
smtp_password = 
smtp_port = 25
smtp_replyto = discard@antiloop.plone.org
smtp_server = localhost
smtp_user = 

[Peter Suter]

The INotificationDistributor extension point of the AdvancedNotification proposal provides a clean way for plugins to implement such alternative notification protocols.

The proposed changes can be found in log:psuter@advanced-notification-mail-distribution.

Several other new extension points and public APIs for plugins are also introduced there. These might have to be reviewed and discussed in some more detail. For example I listed some open questions in the relevant wiki pages (e.g. NotificationEvent API, INotificationFormatter and IEmailAddressResolver).

[Peter Suter]

The proposed changes can be found in log:psuter@advanced-notification-mail-distribution.

Updated in log:psuter@advanced-notification-mail-distribution.2.

These might have to be reviewed and discussed in some more detail. For example I listed some open questions in the relevant wiki pages (e.g. NotificationEvent API, INotificationFormatter and IEmailAddressResolver).

I'll probably just commit the current state. We can still fine-tune later if problems emerge.

[Peter Suter]

Committed to trunk in [13454]. I'll follow up with changes for milestone delete and retargeting events:

trac/ticket/roadmap.py

@@ -35 +35 @@
 from trac.util.text import CRLF, exception_to_unicode, to_unicode
 from trac.util.translation import _, tag_
 from trac.ticket.api import TicketSystem
-from trac.ticket.notification import BatchTicketNotifyEmail
+from trac.ticket.notification import send_ticket_event, BatchTicketChangeEvent
 from trac.ticket.model import Milestone, MilestoneCache, Ticket, \
                               group_milestones
 from trac.timeline.api import ITimelineEventProvider
@@ -775 +775 @@
                 new_values = {'milestone': retarget_to}
                 comment = comment or \
                           _("Open tickets retargeted after milestone closed")
-                tn = BatchTicketNotifyEmail(self.env)
+                event = BatchTicketChangeEvent(retargeted_tickets, None,
+                                               req.authname, comment,
+                                               new_values, None)
                 try:
-                    tn.notify(retargeted_tickets, new_values, comment, None,
-                              req.authname)
+                    send_ticket_event(self.env, self.config, event)
                 except Exception as e:
                     self.log.error("Failure sending notification on ticket "
                                    "batch change: %s",
@@ -827 +828 @@
                               retarget=retarget_to))
             new_values = {'milestone': retarget_to}
             comment = _("Tickets retargeted after milestone deleted")
-            tn = BatchTicketNotifyEmail(self.env)
+            event = BatchTicketChangeEvent(retargeted_tickets, None,
+                                           req.authname, comment, new_values,
+                                           None)
             try:
-                tn.notify(retargeted_tickets, new_values, comment, None,
-                          req.authname)
+                send_ticket_event(self.env, self.config, event)
             except Exception as e:
                 self.log.error("Failure sending notification on ticket batch "
                                "change: %s", exception_to_unicode(e))

[Peter Suter]

Moved draft documentation to:

• TracDev/NotificationApi (Replacing an large table and list of plugins etc. Should that information be kept somewhere?)
• TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.INotificationDistributor
• TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.INotificationFormatter
• TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.IEmailAddressResolver
• TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.IEmailDecorator

[Ryan J Ollos]

Replying to psuter:

(Replacing an large table and list of plugins etc. Should that information be kept somewhere?)

I would just add a link somewhere on the page stating that the pre-1.1.3 Trac Notification API is documented at TracDev/NotificationApi@3.

[Peter Suter]

I'll follow up with changes for milestone delete and retargeting events:

Committed in [13458].

Replying to rjollos:

I would just add a link somewhere on the page stating that the pre-1.1.3 Trac Notification API is documented at TracDev/NotificationApi@3.

Thanks, done.

[Ryan J Ollos]

TicketNotifyEmail and BatchTicketNotifyEmail are marked as deprecated ([13578]), but methods of the classes are called in TicketFormatter. Is the plan to move those methods to the TicketFormatter class when TicketNotifyEmail and BatchTicketNotifyEmail are removed?

[Peter Suter]

Replying to rjollos:

TicketNotifyEmail and BatchTicketNotifyEmail are marked as deprecated ([13578]), but methods of the classes are called in TicketFormatter. Is the plan to move those methods to the TicketFormatter class when TicketNotifyEmail and BatchTicketNotifyEmail are removed?

I think that's exactly what should be done, yes. (The formatting logic of those classes is perfectly fine. The problem with them was the coupling of formatting, sending and recipients gathering, with missing hooks for effective customization. Perhaps more subjectively that inheritance chain has a bit of a ​Yo-yo problem.)

[Ryan J Ollos]

Thanks, I'll proposed the changes in #11901, to be applied in milestone:1.3.1.

[Ryan J Ollos]

I noticed that DEBUG level logging provides no log messages to indicate that trac.ticket.notification is loading.

19:13:45 Trac[loader] DEBUG: Loading trac.ticket.admin from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git
19:13:45 Trac[loader] DEBUG: Loading trac.ticket.batch from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git
19:13:45 Trac[loader] DEBUG: Loading trac.ticket.query from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git
19:13:45 Trac[loader] DEBUG: Loading trac.ticket.report from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git
19:13:45 Trac[loader] DEBUG: Loading trac.ticket.roadmap from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git
19:13:45 Trac[loader] DEBUG: Loading trac.ticket.web_ui from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git

Would the following be advisable?

setup.py

@@ -137 +137 @@
         trac.ticket.admin = trac.ticket.admin
         trac.ticket.batch = trac.ticket.batch
         trac.ticket.query = trac.ticket.query
+        trac.ticket.notification = trac.ticket.notification
         trac.ticket.report = trac.ticket.report
         trac.ticket.roadmap = trac.ticket.roadmap
         trac.ticket.web_ui = trac.ticket.web_ui

19:13:45 Trac[loader] DEBUG: Loading trac.ticket.notification from /Users/rjollos/Documents/Workspace/trac-dev/teo-rjollos.git

In the ticket package the api and default_workflow are also excluded from entry_points, even though they have Components. I'm unsure what determines that a module should be listed in entry_points of the setup function.

[Ryan J Ollos]

A few of the interfaces in tags/trac-1.2/trac/notification/api.py#L34​ have the self parameter. Adding self has been discussed in the past, but other interfaces in Trac and even some in trac/notification/api.py do not have self. Should I just remove them?

[Ryan J Ollos]

comment:24 changes committed to 1.2-stable in r15314, merged to trunk in r15315.

[Ryan J Ollos]

comment:23 changes committed in r15603, merged to trunk in r15604.