[haiku-development] Re: Trac notification enhancements (Was: Translation site bugs in Trac?)
- From: Urias McCullough <umccullough@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Nov 2009 16:30:57 -0800
On Mon, Nov 16, 2009 at 4:20 PM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>> Any recommendations? I would prefer some system where I could
>> configure inclusions/exclusions for email notifications directly from
>> Trac based on attributes of the tickets themselves rather than relying
>> on a mailing list instead.
>
> Well, it's going to be hard to let trac handle it directly, as it would then
> have to determine the set of notification recipients before it sends of a
> mail, instead of simply passing it onto a mailing list. This would call for a
> full featured mail server, which we so far have avoided.
I feel like the mailing list is sort of a poor-man's notification
system in this case... several bug tracking systems I've worked with
(commercial and free) come with a healthy notification system for
custom-tailoring one's notifications using various attributes - it
seems this is a feature still lacking in Trac.
I'm not sure "full featured mail server" is accurate - but it
definitely needs a system integrated with the database to track who
has signed up for what.
Just like our website notifications now (via Drupal's "subscription"
system), the outgoing email notifications likely just require an SMTP
server and account to authenticate with.
> But I think it should be possible to add some of a ticket's attributes
> (component, ...) as an extended header (like X-Trac-Component) to the
> notification mail. We could then use this header to filter the mails as we
> find appropriate.
That could help for sure :)
FWIW, I had previously mentioned this "Trac Hack" on ticket #1740, but
I think the feeling was that it was potentially too hacky to implement
on our system: http://trac-hacks.org/wiki/AnnouncerPlugin - I don't
know a whole lot about Track or how plugins work, so I'll leave all of
this up to those who must maintain it to actually decide if it's worth
pursuing such a feature or not.
There are certainly more pressing matters to attend to - so unless
it's something a relatively large number of people care about, I'd say
skip it.
- Urias
Other related posts:
