> 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.
created and sending aren't quite as helpful for letters, since their
journey through notify and our providers is so different to emails/sms.
So instead, we should return estimated_dispatch_date (in a future PR)
and the status should just read received_by_notify
Added an extra name, 'org_banner', for branding types into branding_type table
Added org banner into user model in database
Added checks for new branding type to ensure that the correct data is passed into the dict
Tested new checks in html email options
> For get all or get one letter the response needs to be updated so that
> it looks similar to admin app.
>
> status: created|sending --> received letter
> new column: `estimated delivery date`: derived from created at date.
> (see how the admin app is doing it)
>
> NOTE:
> At the moment we only have 2 statuses for a letter created and
> sending, but we will want to have other internal statuses that make
> sense to the Notify team but not our services. When we know those
> statuses the status map will be updated at that point.
– https://www.pivotaltracker.com/story/show/150512525
This commit implements the date (not status) part of this story.
