Notification rules

Not all emails are equally important and deserve a notification. Right now K-9 Mail offers the following options:

• never create a notification for new messages
• only notify for messages from contacts
• don't show notifications for messages where the sender address is one of your account's identities
• only notify for messages in certain folders (using the clunky folder class mechanism)
• don't notify during "quiet time"

Often more flexibility would be nice. But I don't want to keep adding special cases. Instead I'd like us to have a generic rules-based system for deciding whether or not to create a notification.

A notification rule should have the following properties:

• description/comment: so users remember what the rule was all about
• enabled state: sometime you want to disable rules without deleting them
• action: the action that should be performed when the rule matches
  • mute: don't create a notification
  • notification_channel: create a notification using a particular notification channel; that way you can have different notification sounds, vibration on/off, etc
  • … maybe more in the future
• action_extra: argument for the 'action' method, e.g. the ID of the notification channel
• potentially multiple clauses: a rule matches when all clauses match
  • property: which property of the message is used for matching (e.g. sender, subject, body, header)
  • property_extra: free-form text to further describe the property, e.g. a particular header name
  • match: how to match the property (e.g. equals, contains, starts-with, etc.)
  • match_extra: free-form text to provide the argument for the 'match' method

We still want dedicated user interfaces for certain features, e.g. mute sender, mute thread/conversation. But we'll also want a user interface that gives access to all properties of a notification rule.

Examples

Separate notification channel for company-internal emails

clause:
  property: sender
  match: matches
  match_extra: *@company.example
action: notification_channel
action_extra: company

High priority messages

clause:
  property: header
  property_extra: X-Priority
  match: equals
  match_extra: 1
action: notification_channel
action_extra: important

High priority messages from company-internal senders

clause:
  property: sender
  match: matches
  match_extra: *@company.example
clause:
  property: header
  property_extra: X-Priority
  match: equals
  match_extra: 1
action: notification_channel
action_extra: important

Mute sender

clause:
  property: sender
  match: equals
  match_extra: annoying-user@domain.example
action: mute

Mute mailing lists

clause:
  property: header
  property_extra: List-Id
  match: exists
action: mute

Mute particular thread

clause:
  property: header
  property_extra: References
  match: contains
  match_extra: <messageid@domain.example>
action: mute

Implementation notes

• Notification rules should be per account (per folder?)
• Create dedicated database tables for notification rules
• Add support for importing/exporting notification rules

No files, tests, or entry points are identified in the issue. Start by locating the existing notification, account, folder, and database code, then define the rule model, matching behavior, user interface, and import/export scope; done means rules can be created, evaluated, and managed without the current special-case limitations.