AnnouncerPlugin concerns

This is a list of concerns and nice-to-haves regarding the functionality of the AnnouncerPlugin:

• Email Addresses
  • Keeping the ability to anonymously subscribe to a ticket is important; any validation?
  • Optional verification? This would require sending a message asking the person if they can receive mails, and until they say yes, never sending the notices. An external module to 'get' email would be required.
  • Be sure apostrophes in names work okay.
  • Allow multiple email addresses per user?
  • Should be able to plug-into an email address discovery system; e.g. if 'bob' is authenticated, get their address.
    • It may be sufficient to add an '@…' to the end of an authenticated user in the case of an intranet, but not always. As figuring this out may be slightly complicated, the delivery system should perhaps allow a pluggable
• Delivery
  • Use a subprocess to prevent blocking and not require threads.
  • Allow for an email's Sender field to specify the user who made the change?
  • A /usr/bin/sendmail IAnnouncementDelivererererer module.
  • Messages encryption using GnuPG
  • Test plain text format mailing for proportional font
  • Add some X-Trac-* headers for filtering perhaps?
  • Email URL syntax: Ticket URL: <URL:http://developer.pidgin.im/ticket/1428#comment:2>
• Tickets
  • Change notices should use the label, not the field name, for custom fields.
  • Send notification when a file is attached?
    • Include link to the attachment.
  • Filter not just on 'prop changed', but on /certain/ props. Perhaps, "all, changed=field"
  • Filter on component owner.
  • Filter on "changed by..." E.g., self, vs others.
  • A "trivial change" notice? Let users filter on "non-trivial"
  • Per-ticket watching beyond the subscription rule-system; e.g. in the ticket view one can click "Watch Me" with various options. "New comments", "status changed"... etc.
  • ​t:#6306 bug: ticket type names (closed)
• A Mailing List-type subscription? E.g., a list of users can receive a message on a new release? Notably would require an IMilestoneChangeListener.
• Wiki
  • Notify on change, delete, (rename?)
  • Notify on attachment add
• Milestone
  • Notification on set-date, change-text, completion
• Preference UI
  • Consider tile the preference boxes after a certain threshold of boxes are available.
• RSS distribution?
• Other nice-to-haves:
  • ​trac:#5670: Refactoring of general NotifyEmail class to make it easier to subclass