On 06/01/2008, Stephen Hansen <[EMAIL PROTECTED]> wrote:
> 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.1
> Upgrade.". 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 :)
I don't have the time to comment on everything in this mail, but overall
I think it's a good approach. From your description, this could be
entirely written as a plugin using the various I*ChangeListener
interfaces already in Trac. The question of whether it goes into core
Trac (replacing the existing system) can be deferred until it's complete
as it shouldn't (at first blush) require any patching of Trac core.
You'd also probably have to implement a backwards compatibility layer on
top of this system. eg. if "always_notify_owner" is set, an
ITicketChangeListener implementation adds a subscription for that user.
You should also definitely talk to Emmanuel Blot (eblot). He wrote the
original notification system and I believe he has been considering
extending it.
--
Evolution: Taking care of those too stupid to take care of themselves.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
