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.
So that when the admin gets notifications, the template they return
also has a "redact_personalisation" boolean attached to it. Note, it
won't do the redacting on the api - that'll be part of the admin.
Under the hood, this uses an association_proxy, which is essentially
black magic. But it proxies the `redact_personalisation` property of
`TemplateRedacted` onto the `Template` object, so that Marshmallow
can pick it up.
Note: NOT currently added to NotificationWithTemplateHistory
If passing in `redact_personalisation` to the template update endpoint,
we should mark that template permanently as redacted - this means that
we won't ever return the personalisation for any notifications for it.
This is to be used with templates containing one time passwords, 2FA
codes or other sensitive information that you may not want service
workers to be able to see.
This is implemented via a separate table, `template_redacted`, which
just contains when the template was redacted.
If the service has not set the url then nothing happens.
If the request to the service url returns with 500 or greater the task is retries.
The task is created when the SMS provider post the inbound SMS.
