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.
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.
You're not alone...
> I'm
> probably going to implement my own system again.
Oh, this makes me very very happy. It is on my todo-list as well, but
given my workload, it's more of a oh-I-wish-list than a todo-list.
> 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.
Interesting idea, and way better than what we have today for sure. I have
given the notifcation system some thought as well ("various checkboxes
turning on and off certain states" might be me), so I wanted to chip in
with my two cents.
My original thought was as follows (short version):
- Each ticket has a notification section where you can specify which
events you want to be notified for that particular ticket (e.g. when a
comment is added, when status changes etc).
- In the preferences, each user can set default rules that are
automatically applied when a ticket is created (e.g. when owner, notify on
all changes, when reporter, only notify on comments, status and
milestone). But the user can still change the type of notification he
wants on each and every ticket. I guess these rules could be similar to
the filters you were thinking of.
I love the filters you propose - that's way more flexible and powerful
than what I had envisioned, but I also miss the possibility of adjusting
the notification settings for each and every ticket. Of course, adding
notification for a single ticket is just a matter of creating a
subscription with "ticketid=433", but if you want to change the filter for
a ticket that already is caught it starts getting cumbersome.
Have you given this aspect any thought?
> So it ends up yielding ( "email", "joe", "j...@example.com"),
> ( "email", "bob", "b...@example.com"), ( "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.
Oh, that's neat. I really like that :-)
> 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
> :)
As Alec suggested, a plug-in is the way to go. It will be available as
soon as it is finished (don't have to wait x months for the 0.12 release),
and you don't have to worry whether it will be accepted into the core or
not. You might discover that you need some new extension points, but these
should be fairly easy to get into the core.
- Endre
Actually, I did not wrote it: I mostly fixed some bugs in the
notification format so that Trac complies with RFCs and it works with
most MUAs (email clients).
Notification subsystem needs a major rewrite, and the last time "we"
talk about it (many months ago) IChangeListener interface was to be
used to replace the current notification architecture.
There was already to many changes scheduled for 0.11, so it has been
decided to postpone notification changes to the next release (0.12).
However, before starting any work on the notification architecture, we
need to go through the very long list of notification enhancement
tickets (and suggestions about the various roles of
notification-related options and fields). This is required to define
which features should be left in the Trac core, which API(s) should be
offered to plugins, etc.
The notification option set also needs to be cleaned up and simplify.
Another big change is to move system-wide settings to user settings.
Notification in 0.12 is likely to break compatibility with previous
release of Trac (both from an API perspective and from a configuration
perspective).
Cheers,
Manu
Interesting idea, and way better than what we have today for sure. I have
given the notifcation system some thought as well ("various checkboxes
turning on and off certain states" might be me), so I wanted to chip in
with my two cents.
My original thought was as follows (short version):
(snip per-ticket notifications and default choices)
I love the filters you propose - that's way more flexible and powerful
than what I had envisioned, but I also miss the possibility of adjusting
the notification settings for each and every ticket. Of course, adding
notification for a single ticket is just a matter of creating a
subscription with "ticketid=433", but if you want to change the filter for
a ticket that already is caught it starts getting cumbersome.
Have you given this aspect any thought?
As Alec suggested, a plug-in is the way to go. It will be available as
> 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
> :)
soon as it is finished (don't have to wait x months for the 0.12 release),
and you don't have to worry whether it will be accepted into the core or
not. You might discover that you need some new extension points, but these
should be fairly easy to get into the core.