similar to sms/email, however, for consistency with response values
and internal storage, rather than supplying an "email_address" field
or a "phone_number" field, supply an "address_line_1" and "postcode"
field within the personalisation object.
in tests, we were replacing os.environ with a basic dict so that
we didn't overwrite the contents of the real environment during tests.
However, os.environ doesn't accept non-str values, so this commit
changes the fixture so that it asserts all values set are strings.
We needed to change how we store ip whitelist stuff in the env because
of this.
I updated the InboundSms and TemplateRedacted model to include an index in the db.
Dropped service_permissions.updated_at column since we are not auditting the table
Replace labels by adding a key kwarg in the model for status.
We still need this as sqlalchemy attmempts to look for `notification_status`
on the model (Notification/NotificationHistory). To achieve true ORM mapping
(map status -> notification_status) we need the key kwarg.
More here:
http://docs.sqlalchemy.org/en/latest/core/metadata.html#sqlalchemy.schema.Column#key
There are a variety of ways a notification can be created - via the
API, via CSV, via one-off messages, via the same but sent as a test -
the point is, there are lots of entry points, and lots of inconsistency
about how personalisation may be sent in. If there are no
personalisation options in the template, we may get either `None` or
`{}` - if the value is None, to avoid an error in our encryption lib,
we just store None in the database.
THIS ENDS NOW!
We've had some problems on the front-end that is caused by
notifications having the `None` value. This commit changes the
personalisation property getter and setter to store/return `{}`
rather than None.
