`Notification.template_history` relationship has been removed but
we want to keep the `template_history` key in existing notification
serializations, so we serialize it from `Notifications.template`.
This keeps the data format the same, but both `template` and
`template_history` keys will now contain data from the `TemplateHistory`
instance.
by hitting POST /<user_id>/email-code, we create an email two factor
code to send to the user. That email contains a link with a token that
will sign the user in when opened.
Also some other things:
"email verification" (aka when you first create an account) doesn't
hit the API anymore
refactor 2fa code verification and sending to use jsonschema, and share code between sms and email
Die marshmallow die!
In future changes, services will be able to control whether their text
messages will be prefixed with the name of their service.
This commit:
- adds a column to store the value of that setting
- makes the service model take notice of it, if it were to have a value
set
It doesn’t:
- provide a way of setting the value of this column
Currently the column can have three values:
- `None` – ignore it (this is what all current services will start as)
and continue to determine whether to prefix messages by looking at the
sender
- `True` – always the service name to the start of text messages
- `False` – never add the service name to the start of text messages
In the future we’ll migrate all services to be either `True` or `False`,
the `None` will go away and all services will have direct control over
the setting.
If the service is sending messages from GOVUK, then its messages should
be prefixed with the service name. Right now this logic is:
- worked out separately in the admin app and API
- isn’t aware of multiple senders
This commit moves the logic to one place (the service model). It does
this in a slightly naive way, in that it only looks at the default
sender, not the actual sender of the message.
In the future this will go away because we’ll move it to being a setting
that’s controlled independently of the service name. But this is the
first step towards that.
fixup! Add prefix SMS with service name to service model
NotificationStatistics was added as a spike but didn't work out as expected. This is finally removing all that unused code.
I'll drop the table in the next PR
> So that we can default services to their appropriate text allowance,
> we need to find out what sector they're in. So let's start collecting
> that from teams as they create new services.
In order to work out what a team’s allowance should be, we need to know
what part of government they’re from. We’re going to do this logic in
the admin app and then `POST` the allowance to the API.
So all we need to do with the information that the users give us is
store it against the service, so we have a record. Doesn’t need any
logic doing as a result of it, doesn’t need foreign keying to the
organisations table, etc.
On the frontend, we’re letting users register with international phone
numbers. So we shouldn’t block users from doing this on the API side.
Same thing for the whitelist, where we’re also allowing international
phone numbers now.
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
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
This allows us to reference it across the API code base and return it in the API.
But not currently attached to the service DB model - a static method on the class.
- uses new utils methods to validate phone numbers
- defaults to International=True on validation. This ensures the validator works on all numbers
- Then check if the user can send this message to the number internationally if needed.
