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.
The use for the public template API is for building caseworking systems
or similar, where you might need a list of templates to pick from (ie
instead of using the Notify web interface to pick from and send a
message).
Right now our API isn’t returning the template name as part of the
response. The name is a useful, human-friendly way of identifying a
template.
This commit changes the response to include the name.
Some clients will need updating before this can be useful.
