We changed the `update_service` method to only update indivdual
attributes of a service, and only allow it to update specified
attributes: 0cfe10639a
We neglected to specify `research_mode` as one of the allowed
attributes.
This broke the app’s ability to put a service in or out of research
mode.
This commit:
- makes sure the tests cover this eventuality
- fixes the bug by specifying `research_mode` as one of the allowed
attributes
Mutating dictionaries is gross and doesn’t work as you’d expect. Better
to have the function return a new dictionary instead.
Means we can be explicit that `created_by` is one of the allowed params
when updating a service.
To prevent typos and inadvertently updating something we shouldn’t,
this adds some filtering to the update_service method to make sure it
is only allowed to update certain attributes of a service.
The service API client was updating every attribute of a service. Which,
while kinda clunky, is fine…
…until something calling it doesn’t pass in every attribute of the
current service. It was then defaulting optional parameters to `None`.
Which resulted in a bug whereby every time a service was set to live,
its `reply_to_address` and `sms_sender_name` got overwritten to be
empty.
This commit changes the `update` method to only require the service ID,
and pass whatever other named arguments it received straight through to
the API. The API handles partial updates just fine (I think).
When you make a ‘normal’ API key it won’t work as described until your
serivce is live.
We should make this clear at the point at which you choose this key.
In research we found that developers orientate themselves around the
API clients rather than the documentation.
We should get them to the client documentation as quickly as possible.
We currently link to the API documentation in three places:
- API integration page
- global footer
- template ‘API info’ page
For the first two this commit:
- removes the link to the documentation
- adds links to each of the 5 clients
For the last one it just removes the link entirely.
Similar to how we do it on the check page, we should indicate if there
are more results than we can show. No-one’s really complained about the
absence of this, but it can’t hurt.
The CSV report isn’t very useful until it has all the rows from your
original file. So we shouldn’t show you the link until all notifications
have been created.
Until this point, it’s useful to know how much longer you need to wait,
so this commit adds a percentage count of how much of the file has been
processed.
The difference between created and sending isn’t something a user should
have to care about. So this commit:
- counts created and sending as the same thing
- displays and notifications which have a status of created as sending
Processed is not an easy to understand thing, and the overlap with
sending/delivered/failed is not easy to intuit.
‘Total’ is a much easier concept to grasp (it relates directly to your
file), and it’s less distracting because it doesn’t change.
