> I ask because the basic email-notification has never worked for my
> needs; I
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", "[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.
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
