Sandbox proposal: branch for email notifications
Emmanuel Blot
I've been through the list of open tickets about the notification feature.
I've tried to roughly classify the tickets to see what are the
requested enhancements and the yet-to-be-fixed issues. Please find
this list below.
I'd like to start a new branch in the sandbox to start working on
these features.
I'd also like to discuss about two very important features that would
ease the implementation of notifications:
1. Wiki parser / formatter separation
This would be useful for generating pure text message and HTML messages
2. Use of event listener to trigger email notification
(ITicketChangeListener and the like)
This would be useful to generalize notification for non-ticket
events (such as the often requested wiki change notifications)
Thoughts / Feedback?
= Open ticket about email notifications =
=== Address presentation ===
#153 Email address obfuscation/truncating
#2642 it would be nice if the ticket view would reflect the
smtp_always_cc field just so that things are more transparent
#3120 [PATCH] cc field in tickets should be remove if smtp isn't enabled.
=== Preferences ===
#1459 Redesign CC field
#2073 flexible ticket notification rules
#2247 [PATCH] Option to prevent notification to self
#4056 Notification Preferences
=== Notification events ===
#731 Allow Trac to send commit information email when the " sync "with
the repository
#1333 New tickets should have a default owner
#1660 Patch to get email notification (with diff) of wiki changes
#2259 No notification email when adding an attachment to a ticket
#2311 No notification email on owner change for the old owner
#3709 Notification of old and new owner
#4281 Notifications should be sent only after attachment is uploaded
#4519 [PATCH] Feature: component owner ticket notification
=== Bugs ===
#3780 Notification may not be sent if owner/reporter is the updater
#4393 notification sent to the wrong receipient
#4520 Ampersand in [project] name is incorrectly escaped in email notifications
=== Email content ===
#1359 Add ticket change email headers to allow more intelligent
filtering of ticket notification emails
#1480 Please add possibility for include component in subject for email notify
#2378 Format of email notifications
#2622 Show ticket status in notification email
#2625 Add option to send HTML mail messages
#3054 Include attached files with added attachment e-mail
notifications for tickets.
#4270 Ticket CC emails contain wiki formatting
#4604 Make a special email subject when the ticket name changes.
#???? Email templates
=== Email address / domain ===
#2766 Trac treats usernames with '@' as email when sending notifications
#3212 notification email check too strict
#4286 Accepts email addresses without validation
#4372 [PATCH] Sending of notification fails using .local top level domain
=== Doc ===
#2887 confusing TracNotification documentation
#4213 settings for mail when ticket chances
=== MTA / delivery ===
#2335 POP before SMTP support on notification
#3870 alternate notification submission (non-SMTP) using sendmail program
=== Address source / user details ===
#2245 Enable trac-admin to configure "user settings" (e.g. e-mail address)
#3162 LDAP support for e-mail notification
=== Cron-like tasks ===
#1962 Due dates on tickets & email notification on overdue dates
=== Likely to be discarded ===
#3447 [patch] Email Notification: Local users, Reply-To, Message-Id
Cheers,
Manu
Christian Boos
> Hi All,
>
> I've been through the list of open tickets about the notification feature.
> I've tried to roughly classify the tickets to see what are the
> requested enhancements and the yet-to-be-fixed issues. Please find
> this list below.
>
Great!
> I'd also like to discuss about two very important features that would
> ease the implementation of notifications:
> 1. Wiki parser / formatter separation
> This would be useful for generating pure text message and HTML messages
>
For the HTML messages, do you think we need something else than the
current wiki_to_html way?
For the text messages, I agree, we need a new "wiki_to_text" formatter,
which would take care of expanding the links, replacing some common
formatting idioms ('''...''' pairs to *...* ones, etc.)
The splitting, while not strictly required, would probably make things
easier.
> 2. Use of event listener to trigger email notification
> (ITicketChangeListener and the like)
> This would be useful to generalize notification for non-ticket
> events (such as the often requested wiki change notifications)
>
Yes, for a variety of reasons, I think that a generalized notification
scheme would be useful.
See
http://trac.edgewall.org/wiki/TracDev/Proposals/Journaling#Notifyingchanges
> I'd like to start a new branch in the sandbox to start working on
> these features.
>
I myself refrained creating several new branches since cmlenz announced
he was willing to go on with the setuptools effort. I think that new
branch should wait for this restructuring to happen, then we can base
further work on a structure that will likely stay for 0.11 and 0.12, at
the very least.
This in turn needs that we go through the discussion concerning the
security branch...
This is important not only because of the need to get these features in
0.11, but also because the changes there are enablers for the the
generalized event notification mechanism.
After that, sure, I'm in favor of creating a new 'notification' branch.
-- Christian
Tim Hatch
just wanted to discuss a couple of things mentioned in the mail while
it's active)
> > I'd also like to discuss about two very important features that would
> > ease the implementation of notifications:
> > 1. Wiki parser / formatter separation
> > This would be useful for generating pure text message and HTML messages
>
> For the HTML messages, do you think we need something else than the
> current wiki_to_html way?
I'm +1 on adding an option for html notifications and looked at it
once before. There's a large piece of code for formatting the faux-
table in ascii that could be factored out into util too, I think.
> For the text messages, I agree, we need a new "wiki_to_text" formatter,
> which would take care of expanding the links, replacing some common
> formatting idioms ('''...''' pairs to *...* ones, etc.)
Could this be more simply done by wiki_to_html then work on Genshi
parse events? I'm thinking of not only expanding the links but
putting them as footnotes if they're rather long.
Tim
Emmanuel Blot
> For the HTML messages, do you think we need something else than the
> current wiki_to_html way?
No I think it would be ok.
> The splitting, while not strictly required, would probably make things
> easier.
Yes, that was the idea. Is there any update on this topic? Will it
make it for 0.11 or more likely 0.12?
> http://trac.edgewall.org/wiki/TracDev/Proposals/Journaling#Notifyingchanges
> I myself refrained creating several new branches since cmlenz announced
> he was willing to go on with the setuptools effort.
No problem to wait, although there is an important amount of work for
all the notification improvement. When would happen the merge of the
setuptools feature?
Cheers,
Manu