#12: Improved notification policies

Contents

1. Motivation
2. Proposal
3. Implementation

Proposed by

Martin Aspeli

Proposal type

Architecture

Assigned to release

• Poi 2.0 (Unreleased)

State

being-discussed

Motivation

Stop spamming me (but tell me what I need to know). :-)

Proposal

This infrastructure should probably exist as a service outside Poi. Ideally, there would be a registry of notifications, organised by Provider (i.e. the product, Poi), then Component (i.e. one for each tracker, indexed by UID or path, perhaps), then Notification (i.e. one for issue added, one for response added, etc.).

Users should be able to subscribe to notifications at any one of these levels, e.g. all notifications for a component, or only specific notifications. Users should also be able to set some basic preferences, such as whether they prefer plain text or HTML mail.

The tool should also include functionality for actually sending the emails, evaluating email templates, validating addresses etc.

Poi would then be able to register its notification emails with this tool, and expose the specific subscription options on a per-tracker basis.

Implementation

At the very least, we should investigate:

• PloneSubscription
• FatSubscription

Using Five/Z3 technologies such as events and interfaces/adapters for subscribable objects and subscribing member objects would seem a good way to go.