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:>
  • 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
Last modified 6 years ago Last modified on Mar 30, 2016, 5:18:24 PM