H'lo.
On the 0.12 milestone (and in the 0.12 thread down below somewhere), it
talks of "Notification Architecture" being a possible goal, and I see quite
a few tickets all related to the same things-- people wanting more or less
messages, on more or less subjects. And different information being sent.
There's a linked proposal that seems to talk of a different /kind/ of
notification-- transactional events passing about the internals-- but I
don't see how that's related directly.
I ask because the basic email-notification has never worked for my needs; I
wrote my own module a few years ago when Trac was a much simpler thing, and
now that I'm migrating our environment back to a vastly prettier Trac, I'm
probably going to implement my own system again. Unless someone else has
already written half of one and it may end up in 0.12 or someone has a
better idea of how to implement it :)
I have in mind a modular system where users can easily (in Preferences, or
whatever) "subscribe" to certain notifications. They can filter these in a
flexible but mostly simple way, and then declare where they want them to go.
Global options don't work for me; and neither do the proposals made in the
t.e.o tickets to add various checkboxes turning on and off certain states. I
need something per-user configurable online, and capable of filtering (in at
least the simplest way) and determining to receive notices based on factors
besides owner/reporter/cc.
There'd be default subscriptions that mimic what basically happens now, but
more fine-grained control if they need it.
For example, I could create a subscription that was basically:
"realm=ticket, category=created, condition=all, when=severity >= critical",
and declare this should be emailed to an alert address that normally doesn't
get trac-emails. A manager wants to receive notices when any ticket is
changed in trac, but doesn't want to receive his own changes.. so he'd
subscribe to "realm=ticket, category=changed, condition=others". The project
managers, installers, and even a customer want to get a message to any issue
that has the "Install-Rome 4.1 Upgrade" milestone, so they'd "realm=ticket,
category=created|changed, condition=all, when=milestone = Install-Rome
4.1Upgrade.". They don't want to have to add themselves to the CC's
for them
all.
My idea for implementing this at present involves around objects
implementing two interfaces; ISubscription and IDelivery (Names temporary),
then a tangible object that is used to interface to these systems.
There would be lots of ISubscription components; each one registers a list
of realms it can handle subscriptions for, and a list of categories in those
realms it knows how to check for. The default TicketSubscription object
would report that it can handle subscriptions for the "ticket" realm, and
categories (off the top of my head), ("created", "comment added",
"propchanged", "status changed") or whatever. The WikiSubscription would do
the same, but for its own realm. Plug-Ins could enhance these. They may send
messages themselves, and so add new realms; or they may add a category to an
existing realm that indicates they are able to determine if someone should
hear a notice based on details the default system doesn't have. Say one of
the time-tracking modules could send notices of time-events to HR who are
cracking down on overtime. Or whatever.
The Subscription components are basically responsible for providing a list
of people who are interested in a given event. A Plug-In might add
categories for messages it sends itself, or just add the ability to make the
determination in a different way that someone is interested in a category
that comes with the base systesm.
Then there is the IDelivery component, that can take a notice and a
subscription and actually send it out. The EmailDelivery component does
basically what NotifyEmail does; but an IrcDelivery or SMSDelivery is
possible to. I haven't decided if it can handle formatting itself or just
transmission, with an IMessageFormatter out there.
The connection between these 'plug-able' components is the
NotificationSystem (or whatever).
One would do something like:
notifier = NotificationSystem(self.env, ticket)
notifier.notify("comment added", commentingUser, message, "Optional short
message doing a quick summary(the IrcDelivery sends this instead!)")
The NotificationSystem then checks to see if it has anything registered that
can handle notifications from the ticket realm; if not? It discards the
message. If so, it then checks if any of those know how to determine if
someone is subscribed to the "changed" category. TicketSubscription does, so
it passes the details to it.
TicketSubscription scans over the "subscription" table, determines Joe wants
to get a message anytime someone messes with his component, Bob wants to get
a message anytime someone fiddles with his issues(but does not want to
receive a message if he is the fiddler), and Daniel wants to stay on top of
any tickets with a high priority-- which this is.
So it ends up yielding ( "email", "joe", "[EMAIL PROTECTED]"),
( "email", "bob", "[EMAIL PROTECTED]"), ( "im", "daniel", "aim:thebossman")
NotificationSystem then checks to see if it knows any IDelivery components
that know how to handle "email" destinations, and it finds one so it sends
it details on the event and Joe and Bob's addresses. Then it discovers
InstantMessageDelivery knows how to handle "im" destinations, and so on and
so forth.
Once the basic system is in place, I planned on writing subscription
handlers for all the types of objects that send NotifyEmail right now, and
then it should be able to just readily replace them.
So! Ahem.
Is anyone considering/planning a flexible notification system in particular
for 0.12 (or 0.13, or...) Has work been done already? If no, and no, I'm
going to end up doing the above just to satisfy our own needs. Unless the
idea floating in my head for /how/ ends up not working at all. Ahem. Is such
a system desirable in core-Trac? If not I'll just keep it when I'm done :)
--Stephen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
