Files
@ 3af545e1d7ef
Branch filter:
Location: rattail-project/rattail/docs/narr/email.rst
3af545e1d7ef
5.3 KiB
text/prs.fallenstein.rst
Update changelog
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 | .. -*- coding: utf-8 -*-
Email Notifications
===================
Often it is useful to send email notifications out to certain folks when
certain things occur or are noticed within the business logic. Rattail assumes
that you might define any number of such events for which email should be sent
out, and of course that you may want different recipients etc. for each event.
With this in mind, the following email subsystem exists.
From Code
---------
The Python code is listed before the configuration syntax, as it best
illustrates the *reasoning* behind the config syntax. Here is a simplistic
notification example:
.. code-block:: python
from rattail.mail import send_email
def my_business_logic(config, yesterday_sales):
max_sales = config.get_int('myapp', 'max_sales')
if yesterday_sales > max_sales:
send_email(config, 'sales_max_broken', {'sales': yesterday_sales})
Here also is the API doc for :func:`rattail.mail.send_email()`.
The point here is that ``send_email()`` should require nothing more than a
handle on the current configuration object (which should always be available in
some direct way), a "key" to distinguish the particular type of event for which
the email is being sent, and an optional dictionary to be used as template
context when rendering the email body.
Configuration
-------------
There are really three different aspects to the email configuration.
* **Meta Configuration** - transcends "types" of email notification
* **Generic Configuration** - common to all types of email notification
* **Specific Configuration** - unique to a particular type of email notification
Note that all configuration for this system will fall under the
``[rattail.mail]]`` section within your config file(s).
Meta Configuration
^^^^^^^^^^^^^^^^^^
This aspect of configuration consists of settings which have nothing to do with
the "type" of email notification involved. Instead of listing and describing
them separately (for now), here is a config snippet which defines each::
[rattail.mail
smtp.server = localhost
smtp.username = mymailuser
smtp.password = mymailpass
templates =
rattail:templates/email
myproject:templates/email
.. todo::
Need to explain current limitations of SMTP authentication.
.. todo::
Need to properly explain email template path setting.
Generic Configuration
^^^^^^^^^^^^^^^^^^^^^
This aspect of configuration consists of settings which may (but need not be)
overridden for any specific "type" of email notification. That is, they
provide the default value if no specific override exists. Again, here is a
config snippet which defines each::
[rattail.mail]
default.from = Rattail <rattail@example.com>
default.to =
"Admins <admin@example.com>"
"Managers" <manager@example.com>"
default.subject = [Rattail] Notification
Note that the "from" address is interpreted as a single address in all cases,
and therefore does not require quotes; same goes for the subject. However the
"to" address *does* require quotes around each individual address within what
may (but need not be) a list.
Note also that it is generally assumed that you *will* define each of the
settings above; this makes optional all Specific Configuration (below).
Specific Configuration
^^^^^^^^^^^^^^^^^^^^^^
These are settings which override those described in Generic Configuration
(above), and are specific to a particular "type" of email notification.
Each "type" of notification must have a unique "key" by which it will be
distinguished. This key is then leveraged within the config syntax to define
settings specific to the type. For instance, if there is a key "foo", then
this might be valid config for the "foo" notification type::
[rattail.mail]
foo.from = Rattail Foo Alerts <rattail-foo@example.com>
foo.to = "Foo Interested Parties" <foo@example.com>"
foo.subject = [Rattail] Foo Is
It is important to note that the key ("foo" in this example) cannot be created
by way of configuration alone. Business logic code essentially "invents" a new
type of notification any time a call to :func:`rattail.mail.send_email()` is
made; the notification type will from then on be designated by the ``key``
argument provided to that function. Any config settings designated by a key
for which no code will attempt to send email (i.e. "made-up" keys within the
config file) will be ignored.
The key name should ideally be descriptive for humans' sake; this will also
help to ensure it is unique. Something like "sales_max_broken" is of course
much better than "foo" in that regard. But again, one must ultimately consult
the code to determine what key should be used for configuring which conceptual
type of notification. The "default" key is reserved for Generic Configuration
(above).
Note also that since it is assumed you will have already provided Generic
Configuration, you need only override those settings for which the generic
value will not suffice. For instance it is very common to override the
recipients for a specific notification, but the sender address is overridden
less often.
.. Templates
.. ---------
.. Currently there is only support for `Mako`_ templates. It is assumed that
.. adding support for others would be trivial, but the reason for which to do so
.. has yet to present itself.
.. .. _Mako: http://www.makotemplates.org/
|