The job is complete when all notifications are delivered or failed.
The report is complete once we have all notifications are in the
database.
This commit changes the meaning of the percentage from the former to the
latter. This is how it was before we removed the aggregate stats for
jobs.
It’s useful to know how many notifications we’ve handed off to our
providers. This is a measure of how complete the processing of the job
is.
This is important, because once the job processing is complete then you
can accurately reconcile the report with the CSV file that you’ve
uploaded.
This was an early reckon feature. There were a few of problems with
it:
- it worked on the service, not just on the API keys as described
- it was back to front, ‘suspending’ a service set `active` to `True`,
reactivating it set `active` to `False`
- no part of the API actually respected the `active` flag on a service
The same intent can be acheived by either:
- revoking an API key
- having a platform admin put your service back into trial mode
So this commit removes the link and the code behind it.
There’s no way of seeing what the current settings are for a service
without individually going to the pages where you can change them.
This commit replaces the list of settings with a table. The table plays
back the current value for each setting.
This is a pattern that has worked well on various services[1] as well
as on our own user profile page.
1. https://designpatterns.hackpad.com/Check-your-answers-page-2DSpTH9J0wU
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).
