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.
In the future, we may want to return additional information about
placeholders.
We came up with three possible formats:
1. list of `dict`s, eg `[{'name': 'first name', 'required': True}]`
2. `dict` of `list`s, eg `{'required': ['first name']}`
3. `dict` of `dict`s, eg `{'name': {'required': True}}`
I don’t like 1. because it’s harder to traverse if all you want is the
name of the placeholders, and suggests that you could have two
placeholders with the same name (which you can’t). I don’t like 2.
because it only lets the data be sliced by one dimension (unless the
inner lists aren’t exclusive, in which case you’d need to filter
duplicates when just listing placeholders).
I think 3. has the two advantages of:
- represents that personalisation is unique, ie you can’t pass back in
two different values for the same key
- is forward compatible, ie we can add many more properties of a
placeholder without breaking anything
So this commit implements 3.
> Currently when retrieving a template via one of the clients, we do
> not return the personalisation fields that are required for that
> template.
>
> This is useful for services who want to perform template validation on
> their own systems. A service user has also requested this.
– https://www.pivotaltracker.com/story/show/150674476
This commit adds an extra attribute to the JSON response containing an
array of the placeholder names. This key is called "personalisation",
to match the argument that developers use to pass in the values of
placeholders.
Add new endpoint to allocate a specific number to a given service.
This will allow the platform admin user to choose a number when setting the inbound_sms permission for a service.
