I think there was some imports missed when resolving merge conflicts.
Also I'm not sure why the test_update_letter_notification_to_sent or error passed, I've updated them so they do pass.
we now no longer create a job. At the end of the post there is no
action, as we don't have any tasks to queue immediately - if it's a
real notification it'll get picked up in the evening scheduled task.
If it's a test notification, we create it with an initial status of
sending so that we can be sure it'll never get picked up - and then we
trigger the update-letter-notifications-to-sent-to-dvla task to sent
the sent-at/by.
1. No longer create jobs when creating letters from api 🎉
2. Bulk update notifications based on the notification references after
we send them to DVLA - either as success or as error
this means that if the task is accidentally ran twice (eg we autoscale
notify-celery-worker-beat to 2), it won't send letters twice.
Additionally, update some function names and config variables to make
it clear that they are referring to letter jobs, rather than all letter
content
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.
