= 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 '@address.com' 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. * [AnnouncerPlugin/MessageEncryption 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: ~~ * 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